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PREFACE 


This  publication  is  a compilation  of  the  papers  prepared  for  the  Space 
Shuttle  Technical  Conference  held  at  the  NASA  Lyndon  B.  Johnson  Space 
Center,  Houston,  Texas,  June  28-30,  1983.  The  purpose  of  this  conference 
was  to  provide  an  archival  publication  for  the  retrospective  presentation 
and  documentation  of  the  key  scientific  and  engineering  achievements  of  the 
Space  Shuttle  Program  following  the  attainment  of  full  operational  status  by 
the  National  Space  Transportation  System. 

To  provide  technical  disciplinary  focus,  the  conference  was  organized  around 
10  technical  topic  areas:  (1)  Integrated  Avionics,  (2)  Guidance, 

Navigation,  and  Control,  (3)  Aerodynamics,  (4)  Structures,  (5)  Life  Support, 
Environmental  Control,  and  Crew  Station,  (6)  Ground  Operations,  (7) 
Propulsion  and  Power,  (8)  Communications  and  Tracking,  (9)  Mechanisms  and 
Mechanical  Systems,  and  (10)  Thermal  and  Contamination  Environments  and 
Protection  Systems. 

The  papers  in  each  technical  topic  which  were  presented  over  the  3-day 
conference  period  provide  a historical  overview  of  the  key  technical 
problems  and  challenges  which  were  met  and  overcome  during  the  development 
phase  of  the  Space  Shuttle  Program.  Taken  as  a whole,  these  papers  provide 
a valuable  archival  reference  to  the  magnitude  and  scope  of  this  major 
national  achievement. 

Because  of  the  large  volume  of  material  prepared  for  the  conference,  this 
publication  is  divided  into  two  parts. 

This  publication  was  prepared  through  the  efforts  of  the  staff  of  the 
Technical  Information  Branch,  Management  Services  Division,  Johnson  Space 
Center. 


FOREWORD 


The  achievement  of  operational  status  of  the  National  Space  Transportation 
System  represented  a historic  accomplishment  for  the  National  Aeronautics 
and  Space  Administration  (NASA),  its  contractors,  and  for  the  United  States. 
To  recognize  this  accomplishment,  NASA  organized  a technical  conference  fo- 
cusing on  the  design  and  development  phase  of  the  Space  Shuttle  Program. 

The  purpose  of  the  conference  was  to  permit  a presentation  by  key  members  of 
the  NASA-Industry-Department  of  Defense  team  of  the  outstanding  achievements 
of  the  program.  Toward  this  end,  the  conference  theme  "The  Space  Shuttle 
Program:  From  Challenge  to  Achievement"  was  selected. 

To  provide  a comprehensive  and  balanced  program  for  the  conference,  the  Con- 
ference Organizing  Committee  selected  10  broad,  technical  topic  areas  for 
which  papers  were  invited  from  individuals  who  played  key  technical  roles  in 
the  success  of  the  design  and  development  program.  An  extraordinarily  fine 
selection  of  91  papers  was  submitted  for  the  conference  representing  the 
contributions  of  6 NASA  field  centers,  the  Department  of  Defense,  2 univer- 
sities, and  27  industrial  organizations.  Over  the  3-day  period  of  June  28- 
30,  1983,  these  papers  were  presented  at  the  Lyndon  B.  Johnson  Space  Center 
in  a format  of  multiple,  parallel  technical  sessions,  fully  satisfying  the 
"Achievement"  portion  of  the  conference  theme. 

The  "Challenge"  aspect  of  the  conference  theme  was  provided  by  Lieutenant 
General  James  A.  Abrahamson,  NASA  Associate  Administrator  for  Space  Flight, 
who  presented  the  conference  keynote  address;  and  by  Dr.  Maxime  A.  Faget, 
President  of  Space  Industries  Incorporated  and  former  Director  of  Engineer- 
ing and  Development  at  the  Johnson  Space  Center,  who  organized  and  moderated 
the  discussions  of  a panel  of  distinguished  government  and  industry  execu- 
tives who  presided  over  the  early  days  of  the  program.  Excellent  retrospec- 
tive presentations  were  also  made  by  Dr.  Glynn  S.  Lunney,  Manager  of  the  Na- 
tional Space  Transportation  System  Program,  and  by  Donald  K.  (Deke)  Slayton, 
President  and  Vice  Chairman  of  Space  Services  Incorporated  of  America  and 
former  NASA  astronaut  and  management  official.  The  complementary  combina- 
tion of  technical  papers,  addresses,  and  panel  discussions  provided  a satis- 
fying, synergistic  package  for  the  more  than  1200  conference  attendees. 

As  former  Manager  of  the  Orbiter  Project,  it  was  my  privilege  to  serve  as 
General  Chairman  of  the  Space  Shuttle  Technical  Conference  and  to  recognize 
and  honor  the  team  of  men  and  women  responsible  for  this  historic  accom- 
plishment. 

I am  grateful  for  the  help  and  support  of  the  other  members  of  the  Con- 
ference Organizing  Committee:  Elwood  W.  Land,  Jr.  (NASA  Headquarters); 

James  E.  Kingsbury  (Marshall  Space  Flight  Center);  and  Peter  A.  Minderman 
(Kennedy  Space  Center);  and  to  Norman  H.  Chaffee  (Johnson  Space  Center)  who 
served  as  Conference  Arrangements  Chairman. 


Aaron  Cohen 
General  Chairman 
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ABSTRACT 


The  challenge  of  providing  redundancy  management  (RM)  and  fault  tolerance  to  meet  the  Shuttle 
Program  requirements  of  fail  operational /fail  safe  for  the  avionics  systems  was  complicated  by  the 
critical  program  constraints  of  weight,  cost,  and  schedule.  This  paper  addresses  the  basic  and 
sometimes  false  effectivity  of  less  than  pure  RM  designs.  Evolution  of  the  multiple  input  selection 
filter  (the  heart  of  the  RM  function)  is  discussed  with  emphasis  on  the  subtle  interactions  of  the 
flight  control  system  that  were  found  to  be  potentially  catastrophic.  Several  other  general  RM  devel- 
opment problems  are  discussed,  with  particular  emphasis  on  the  inertial  measurement  unit  RM,  indic- 
ative of  the  complexity  of  managing  that  three-string  system  and  its  critical  interfaces  with  the 
guidance  and  control  systems. 


PROGRAM  REQUIREMENTS  AFFECTING  FAULT  TOLERANCE/RM 


Space  Shuttle  Program  requirements  dictate  fault  tolerance  in  all  systems  other  than  primary 
structure,  thermal  protection,  and  pressure  vessels.  In  the  case  of  avionics  systems,  those  require- 
ments are  specified  to  be  two-fault  tolerant,  or  fail  operational/fail  safe  (FO/FS)  (ref.  1)  as  com- 
monly referred  to  in  Shuttle  terms.  Considering  the  design  life  goals  of  100  missions  and  10  years 
or  more  operational  span,  this  FO/FS  requirement  not  only  appears  reasonable  but  almost  minimally  man- 
datory. Given  a free  hand  in  hardware  provisioning,  meeting  the  FO/FS  requirement  may  have  been  ob- 
tainable. As  would  be  expected  in  a program  heavily  pressed  with  cost  and  weight  constraints,  the 
avionics  designers'  hands  were  not  so  free. 

Providing  FO/FS  fault  tolerance  with  no  holes  or  subtle  escapes  would  most  easily  be  accom- 
plished by  providing  independent  five-string  operation  with  independent  data  inputs  to  each  of  the 
five  strings  and  command  functions  requiring  three  out  of  five  votes  before  execution.  This  approach 
would  obviously  be  costly  in  weight  and  cost  of  wiring  and  avionics  components  but  does  offer  an 
FO/FS  design  approach  that  could  be  void  of  in-flight  failure  effects  concerns  for  two  failures.  It 
would  also  eliminate  the  historically  complex  hardware/software  requirements  for  fault  detection  and 
isolation  since  the  first  two  failures  would  be  transparent.  This  five-string  approach  is  indeed 
being  implemented  in  the  flight-critical  interfaces  of  the  Centaur  payloads  with  the  Orbiter.  The  ap- 
proach was  never  seriously  considered  for  Shuttle/Orb  iter  design  because  of  the  obvious  systems 
weight  and  cost  impacts,  yet  the  FO/FS  requirement  was  maintained. 

The  first  step  down  from  the  five-string  design  to  meet  FO/FS  is  to  provide  four-string  opera- 
tion with  fault  detection  and  isolation  of  at  least  the  first  fault.  Various  schemes  can  be  im- 
plemented at  the  four-string  level  to  choose  proper  data  or  perform  the  proper  command  function,  but 
the  susceptibility  to  the  second  failure  requires  a fault  detection  and  isolation  scheme  to  eliminate 
the  first  failure  before  occurrence  of  the  second  failure  in  order  to  be  FO/FS.  Two  simultaneous  or 
near-simultaneous  (within  the  timespan  required  to  detect  and  isolate  the  first  failure)  failures 
will  defeat  this  approach;  however.  Shuttle  Program  management  has  granted  detection  and  reconfig- 
uration time  in  its  FO/FS  requirement  provided  the  detection  is  reasonably  assured  of  working.  In 
this  scheme,  the  second  failure  is  then  tolerated  by  selecting  the  middle  valued  data  of  the  remain- 
ing three  inputs  and  voting  two  of  three  for  command  functions  or  providing  enough  muscle  in  the  two 
good  command  channels  to  override  the  second  failure  channel.  This  four-level  approach  was  selected 
for  a major  portion  of  the  Shuttle  avionics  and  has  fared  well  with  the  possible  exception  of  null 
failures  in  sensors  normally  operating  about  their  null,  thereby  hindering  the  fault  detection  of 
either  the  first  or  the  second  null  failure. 

The  next  step  down  in  redundancy  while  maintaining  FO/FS  fault  tolerance  is  to  provide  three- 
string  operation  in  conjunction  with  fault  detection  and  isolation  of  both  the  first  and  second  fail- 
ures in  the  system.  Detecting  and  isolating  the  first  failure  in  a three-string  system  is  not  overly 
complex  and  detecting  the  second  failure  through  two-level  comparison  of  inputs  or  outputs  is  straight- 
forward. The  difficulty  in  this  approach  comes  in  isolating  the  second  failure.  Disagreement  be- 
tween only  two  inputs  requires  a decisionmaking  vote  that  is  often  costly  and  still  not  100  percent 
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certain,  such  as  built-in  test  equipment  (BITE),  self-tests,  or  reasonableness  tests.  In  the  cases 
where  isolation  is  still  lacking,  a crew  "guesstimate"  and  manual  reconfiguration  may  be  used  to  sup- 
plement the  auto  RM.  This  approach  can  also  be  costly  and  leaves  room  for  errors.  This  second  fault 
isolation  problem  was  a primary  factor  in  the  basic  four-string  avionics  design  in  the  Shuttle  with 
the  Orbiter  inertial  measurement  units  (IMU's)  being  the  most  notable  exception.  The  basis  for  this 
exception,  as  with  the  other  three-string  systems,  included  weight  and  cost,  reliability  background 
and  history  of  similar  hardware,  and  projected  BITE  capabilities  to  cover  second  failure  isolation. 
Treatment  of  the  second  failure  detection  and  isolation  of  the  IMU's  has  involved  such  extensive  ef- 
forts in  analysis,  verification,  software  changes,  and  flight  procedures  development  that  the  possi- 
bility of  adding  a fourth  IMU  to  the  Orbiter  is  still  under  consideration.  Indeed,  the  complexities 
of  timely  detection  and  isolation  of  two-level  IMU  faults  and  the  capabilities  and  limitations  of  the 
IMU  BITE  design  are  sufficient  to  warrant  treatment  as  an  individual  paper,  accounting  for  the  large 
portion  of  this  paper  being  dedicated  to  IMU  RM.  A considerable  amount  of  the  IMU  RM  design  change 
activity  deals  with  fine  tuning  of  the  data  to  minimize  errors  passed  to  the  guidance  and  control 
systems;  however,  the  final  fault  tolerance  assessment  accounting  for  the  two-level  isolation  problems 
results  in  no  capability  to  isolate  approximately  0.7  percent  of  the  second  faults  and  an  even  more 
disconcerting  0.15  percent  of  the  second  faults  which  can  result  in  selection  of  the  failed  IMU 
(ref.  2). 

Any  further  reduction  in  redundancy  level  below  three  strings  obviously  fails  to  meet  the 
avionics  FO/FS  requirement  unless,  of  course,  the  function  itself  is  not  required  and  is  then  by  defi- 
nition FS  after  the  second  failure.  The  net  result  is  that  Shuttle  avionics  basically  evolved  as  a 

three-  and  four-string  design  attempting  to  provide  fault  detection  and  isolation  capability  to  make 

these  redundancy  levels  equal  to  the  five-string  design  required  to  be  purely  FO/FS.  The  success  of 
this  design  is  not  easily  measured;  however,  there  are  several  key  data  points  to  recount  when  con- 
sidering Shuttle  redundancy  design  versus  a blanket  FO/FS  requirement.  First,  the  Orbiter  avionics 
alone  has  officially  documented  some  255  critical-items  lists  (CIL)  exceptions  to  the  FO/FS  require- 
ment. Secondly,  in  striving  to  meet  the  blanket  FO/FS  requirement,  the  less  than  pure  approach  has 

resulted  in  an  analysis  and  verification  program  of  staggering  proportions.  As  former  astronaut  and 
Orbital  Flight  Test  Manager  Donald  K.  Slayton  stated  (ref.  3),  though  possibly  too  late  to  influence 
the  Shuttle  Program  direction,  there  is  an  unpredictable  but  "high  cost  of  worrying  improbable  pos- 
sibilities." Because  of  the  second  fault  tolerance  requirement  and  the  fault  detection  and  isola- 
tion deficiencies  (delays  in  isolation  and/or  various  degrees  of  escapes),  every  combination  of 
failures,  however  improbable,  must  be  analyzed  and  verified  as  acceptable.  This  is  then  magnified 
by  reconfiguration  actions  planned  to  optimize  the  postfailure  system  configuration,  each  of  these 
obviously  requiring  verification.  In  this  process,  as  is  its  objective,  escapes  from  the  FO/FS  re- 
quirement are  sometimes  discovered,  leading  to  software,  hardware,  and/or  procedural  changes  which, 
of  course,  add  to  the  verification  work.  Quantification  of  such  changes  is  nearly  impossible  but 
some  understanding  of  the  problem  can  be  evidenced  by  the  ever-present  hardware  and  software  change 
boards,  the  approximately  700  pages  of  crew  malfunction  procedures,  the  more  than  1000  pages  of  off- 
nominal  crew  procedures,  the  libraries  full  of  off-nominal  verification  procedures  and  test  reports, 
and  the  more  than  250  software  change  requests  which  have  currently  been  approved  to  the  RM  Flight 
System  Software  Requirements  (FSSR)  alone  (ref.  4). 

Mr.  Slayton's  approach  to  the  problem  was  proposed  basically  as  drawing  a line  in  the  sand 
defining  some  failure  criticality  not  based  on  a blanket  FO/FS  requirement  but  rather  based  on  the 
probability  of  that  failure  (or  combination  of  failures)  to  occur.  If  the  failure  probability  is  de- 
termined to  be  lower  than  that  line,  the  design  would  not  have  to  accommodate  changes  to  meet  the 
FO/FS  requirement.  The  obvious  problems  of  choosing  the  acceptable  failure  probability  and  the 
mechanization  of  determining  the  probability  of  potential  failures  are  admittedly  nontrivial;  how- 
ever, Mr.  Slayton  cites  the  success  of  the  Saturn  5 program  as  a working  example  of  this  approach. 

An  alternate  approach  that  has  essentially  been  described  earlier  is  to  provide  a five-string  op- 
eration with  data  and  command  selection,  based  on  the  middle  value  of  the  five  or  voted  to  require 
three  of  the  five  data  or  command  statuses  to  produce  a functional  response.  The  aforementioned 
weight  and  cost  penalties  of  such  a system  are  understandably  undesirable  and  easily  considered 
unjustified  in  the  preliminary  stages  of  system  design.  Considering  the  historically  costly  change 
traffic  and  verification  activities  that  go  with  the  attempted  development  of  less  than  pure  redun- 
dancy matching  requirements,  the  initial  acceptance  of  the  additional  string  weight  and  cost  may  have 
been  an  effective  overall  decision  for  the  Shuttle/Orbiter  Program. 


IMPACTS  OF  SUBSYSTEM  PERFORMANCE  CHARACTERISTICS  ON  RM 

The  Shuttle  RM  involves  both  hardware  and  software  functional  Implementations,  the  extent  of 
each  determined  by  the  design  and  response  characteristics  of  the  individual  subsystem  element.  As 
with  any  development  program  on  the  level  of  sophistication  and  gross  technical  expansion  of  func- 
tional capabilities  such  as  in  the  Shuttle  Program,  the  potentials  for  hardware  and  software  design 
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deficiencies  are  not  few.  Adding  the  scheduling  demands  typically  forced  on  NASA  programs  compli- 
cates the  situation  by  requiring  parallel  development  of  subsystem  hardware  and  the  associated  appli- 
cations and  RM  software.  This  parallel  RM  design  does  not  then  allow  for  an  individual  line  replace- 
able unit  (LRU)  performance  understanding  beyond  that  established  as  design  requirements  in  the  pro- 
curement specifications.  Additionally,  the  benefits  of  failure  modes  and  effects  analyses  on  the 
LRU's  cannot  be  utilized  in  initial  designs,  since  these  analyses  are  not  completed  sufficiently 
until  final  design  and/or  design  verification  testing  has  been  completed.  Finally,  the  performance 
of  the  LRU's  within  the  system  as  a whole  cannot  be  adequately  anticipated  until  integrated  systems 
simulations  and/or  verification  programs  are  underway  involving  flight  hardware/software  designs  and 
sophisticated  models  of  environments,  aerodynamic  effects,  and  vehicle  dynamic  models.  Development 
of  the  RM  schemes  under  these  handicaps  can  and  did  result  in  many  initial  assumptions  that  turned 
out  to  be  invalid  or  at  least  not  sufficient  to  provide  totally  acceptable  RM. 

A primary  example  of  this  programmatic  dilemma  occurred  in  the  Orbiter  flight  control  system 
(FCS)  interface  with  the  redundant  FCS  sensor  systems.  Providing  the  FCS  with  the  best  available 
rate  and  acceleration  data  from  a quad  redundant  sensor  set  at  first  glance  appeared  trivial.  The 
program  had  provided  the  fourth  sensor  set  after  only  three  had  been  initially  proposed  because  it 
was  recognized  that  isolation  of  the  second  failure  in  dynamic  periods  of  flight  could  not  be 
guaranteed  within  FCS  control  limits.  The  formulation  and  use  of  a software-derived  fourth  input 
was  too  complex  and  laced  with  its  own  shortcomings. 

The  selection  of  the  "best"  data  input  from  this  set  was  considered  to  be  a simple  extension  of 
the  three-sensor  method;  i.e.,  provide  a software  selection  filter  (SF)  which  dealt  with  the  first 
three  inputs  by  simply  selecting  the  middle  valued  input  for  use  by  the  FCS,  substituting  the  fourth 
sensor  input  only  after  one  of  the  original  three  had  been  determined  to  be  failed  (fig.  1).  This  SF 
design  was  baselined  and  implemented  in  the  software  RM  along  with  a fault  detection,  isolation,  and 
reconfiguration  (FDIR)  scheme  that  used  a unit-to-unit  comparison  test  to  determine  whether  a unit 
had  failed.  On  the  surface,  this  approach  was  simple  and  foolproof;  in  final  application,  it  was  not 
so  simple  and  indeed  inadequate.  Two  key  conditions  combined  to  defeat  this  original  approach:  (1) 

to  eliminate  or  limit  false  alarm  exposure,  the  magnitude  of  the  differences  between  units  had  to  be 
significantly  large  enough  to  account  for  unfailed  unit  normal  deviations  (3a),  system  noise,  and 
transients;  and  (2)  the  FCS  control  laws  and  vehicle  responses  aimed  toward  and  generally  achieved 
stable  flight  conditions  within  the  limits  of  times  and/or  magnitudes  established  to  prevent  the 
false  alarms.  The  interaction  of  these  two  factors  resulted  in  a general  inability  to  detect  and  iso- 
late a null  failed  sensor  (fig.  2). 
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FIGURE  1.-  INITIAL  SOFTWARE  QUAD  RM  APPROACH. 
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FAILED  TO  NULL  FAILED  TO  NULL 

FIGURE  2.-  MVS  NULL  FAILURE  SCENARIO. 


For  the  first  null  failure  experienced,  this  was  an  insignificant  event  since  the  SF  still  pro- 
vided a good  output  in  the  form  of  the  smaller  of  the  two  remaining  good  units  or  the  null  if  the  two 
remaining  good  units  were  operating  near  to  and  bracketing  the  null  failure.  With  the  first  null 
failure  included  in  the  SF  set,  however,  the  effects  of  the  second  null  failure  became  catastrophic. 
With  a second  null  failure  in  the  set,  the  middle  value  in  the  SF  will  always  obviously  be  a null.  As 
vehicle  stability  deviates  from  this  point,  the  FCS  will  not  see  the  change  and  quickly  becomes  unsta- 
ble. An  additional  irony  is  that  the  RM  will  actually  declare  a failure  against  the  only  good  sensor 
input  in  the  SF  as  its  output  builds,  deselect  that  sensor,  and  replace  it  with  the  fourth  (good) 
sensor,  only  to  have  it  defeated  just  as  the  first  good  sensor  was.  The  recognition  of  the  inability 
of  the  baselined  RM  to  deal  with  this  dual  null  scenario  was  not  possible  until  the  hardware  and  sys- 
tems models  were  completed  and  evaluation  and  verification  test  facilities  could  be  used.  Verifica- 
tion analyses  showed  the  dual  null  system  effects  to  be  an  unstable  vehicle  in  ascent  and  entry  mis- 
sion phases  for  the  pitch,  roll,  or  yaw  rate  gyros  and  severe  violation  of  the  load  relief  and  g 
limits  for  such  loss  of  the  normal  or  lateral  accelerometers. 

The  risk  associated  with  the  dual  null  deficiency  in  the  RM  was  considered  to  be  extremely  small 
considering  the  relatively  short  period  of  use  of  the  rate  gyros  and  accelerometers.  This  could  be 
further  minimized  by  performing  stim  tests  just  before  lift-off  and  again  just  before  entry,  thereby 
detecting  nulls  and  allowing  proper  reconf iguration.  The  risk  was  not  zero,  however,  and  a proposed 
fix  to  obtain  the  highly  desirable  FO/FS  status  which  involved  a software  modification  only  was  de- 
veloped. The  impact  of  this  software  change  was  evaluated  as  an  increase  in  CPU  requirements  for  the 
SF  from  0.875  to  1.46  percent,  an  increase  in  memory  requirements  for  the  SF  from  75  to  90  words,  and 
a decrease  in  memory  requirements  for  the  FDIR  from  229  to  200  words.  At  this  point  in  the  program, 
the  new  quad  midvalue  select  (QMVS)  SF  was  accepted  as  the  resolution  of  the  dual  null  failure  con- 
cerns for  the  rate  gyros  and  accelerometers.  Since  that  time,  the  body  flap  position  feedbacks  and 
the  solid  rocket  booster  (SRB)  rate-gyro  assemblies  (RGA's)  have  also  been  improved  by  application  of 
the  four  active  inputs  SF  (QMVS)  in  place  of  the  three  active  with  a standby. 

For  flight  control  and  dynamic  response  limitations,  the  QMVS  eventually  proved  to  be  adequate. 
However,  the  verification  analyses  with  dynamic  flight  models  discovered  yet  another  sophisticated  es- 
cape. The  QMVS  SF  was  observed  in  these  verification  activities  as  meeting  the  flight  control  stabil- 
ity requirements  with  dual  nulls  present.  However,  an  unexpected  increase  in  reaction  control  system 
(RCS)  jet  activity  was  resulting  in  significant  increases  in  RCS  propellant  consumption.  Refinement 
of  these  cases  determined  that  with  the  dual  null  failures  and  reasonable  biases  on  the  remaining  two 
sensors,  RCS  propellant  consumption  could  increase  by  as  much  as  a factor  of  four  (ref.  5).  The  con- 
tribution of  the  QMVS  SF  to  this  phenomenon  is  illustrated  in  figure  3. 
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(a)  NO  FAULTS,  | A|  -|B|  <C 


RATE 


(C)  CHANNEL  4 NULL,  |A|  - |B|  < C 


RATE 


(b)  NO  FAULTS,  | A|  -|B|  >C 


VEHICLE  RATE 

SENSED  RATE, 

GYROS  1,  2,  3,  4 

QMVS  SIGNAL  A ® 

QMVS  SIGNAL  B ® 

QMVS  SELECTED  SIGNAL  


(e)  CHANNEL  1,  4 NULL 

FIGURE  3.-  QMVS  SELECTION  FILTER  OUTPUT  COMPARED  TO  VEHICLE  RATE  AND  SENSED  RATE. 


The  QMVS  basically  works  as  illustrated  in  figures  3(a)  and  3(b)  in  that  the  SF  logic  evaluates 
all  four  inputs,  determines  the  two  middle  valued  inputs,  and  selects  one  of  them  based  on  a test  of 
their  difference  between  each  other  (the  "C"  value).  The  "C"  value  is  fixed  based  on  the  reasonably 
expected  null  offsets  between  good  gyros,  null  offsets  between  good  mul tiplexer/demul tiplexer  (MDM) 
channels,  and  MDM  nonlinearity.  It  is  designed  to  prevent  discontinuous  SF  outputs  caused  by 
switching  between  signal  A and  signal  B for  the  no-fault  case  and  yet  provide  satisfactory  rate 
outputs  with  undetected  single  or  dual  null  failures.  Figures  3(c),  3(d),  and  3(e)  illustrate  the 
QMVS  performance  with  single  and  dual  undetected  null  features.  Because  of  the  fine-tuned  FCS  and  ve- 
hicle responses  and  the  typical  operation  at  near  null  vehicle  rates,  the  illustrated  nonlinearities 
in  the  sensed  vehicle  rates  can  result  in  residual  oscillations  and  attendant  RCS  propellant  consump- 
tion as  previously  described.  Evaluation  test  cases  indicated  that  under  the  dual  null  conditions, 
sufficient  propellant  consumption  could  result  in  depletion  and  loss  of  control  unless  the  condition 
was  recognized  and  crew  intervention  was  timely. 
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As  another  escape  from  the  FO/FS  design  requirement,  however  limited  in  probability,  changes 
were  developed  as  candidate  solutions  and  evaluated  in  flight  performance  simulators  to  eliminate 
this  last  caveat  from  the  FCS  RM  verification  status.  With  the  weakness  of  the  QMVS  being  the 
deficiency  of  the  FDIR  to  detect  and  isolate  null  failures  in  the  Shuttle  FCS  environment,  one  obvi- 
ous approach  was  to  bias  the  SF  to  choose  the  more  active  midvalue  parameter  and  stay  with  it  until 
fault  conditions  indicated  that  the  other  midvalue  parameter  was  significantly  more  active.  The  term 
used  to  describe  this  SF  approach  is  interchangeable  midvalue  selection  (IMVS).  The  IMVS  operation 
under  nominal,  single,  and  dual  null  failure  conditions  is  presented  in  figure  4.  The  primary  differ- 
ence in  the  IMVS  and  the  QMVS  is  that  once  the  two  middle  valued  parameters  of  the  four-parameter  set 
have  been  determined  (identically  in  both  approaches),  the  SF  chooses  the  largest  of  these  two  values 
and  sticks  with  that  selection  until  fault  conditions  are  detected  and  then  switches  one  time  only  to 
the  other  midvalued  parameter.  Remember  that  the  QMVS  selected  the  highest  of  the  middle  valued  pa- 
rameters for  dispersions  greater  than  a present  value  "C"  and  the  smaller  middle  value  for  disper- 
sions less  than  "C,"  resulting  in  undesirable  discontinuities  being  provided  to  the  SF  user.  As 
previously  described,  the  discontinuities  and  nonlinearities  of  the  QMVS  SF  in  the  presence  of  dual 
undetected  null  failures  results  in  unacceptable  propellant  consumption.  As  shown  in  figure  4,  the 
IMVS  eliminates  these  discontinuities  and  reduces  the  nonlinearities,  thereby  improving  FCS  effi- 
ciency. Evaluation  test  cases  showed  propellant  consumption  reduction  compared  to  the  QMVS  ranging 
from  62  to  1100  pounds,  depending  on  the  axis  containing  the  null  faults,  the  point  of  fault  inser- 
tion, and  the  biases  assigned  to  the  remaining  two  good  parameters. 

The  IMVS  has  been  approved  for  Shuttle  implementation,  providing  resolution  to  the  current  RM  de- 
sign caveat.  It  will  likewise  serve  as  a verified  approach  in  future  four-string  design  activ- 
ities. One  can  only  wonder  again  whether  the  costs  of  the  changes  from  MVS  to  QMVS  to  IMVS  and 
the  associated  analysis  and  verification  activities  might  have  compared  to  initial  design  implemen- 
tation of  a five-string  system. 


FAULT  TOLERANCE  ASSESSMENT  OF  INTEGRATED  SYSTEMS 


It  has  already  been  pointed  out  that  design  of  the  Shuttle  avionics  systems  to  the  FO/FS  program 
requirement  under  the  weight  and  cost  constraints  which  drove  designers  to  not  demand  the  pure  five- 
string  approach  is  at  best  a complex  and  difficult  task.  Several  of  the  major  exceptions  to  full-up 
redundancy  in  the  Shuttle  avionics  interfaces  are  especially  noteworthy,  specifically  the  universal 
servicing  systems  such  as  electrical  power  distribution,  cooling,  and  instrumentation.  Of  these,  pos- 
sibly the  key  factor  In  concern  for  integrated  systems  failure  tolerance  turned  out  to  be  the  three- 
string  electrical  power  distribution  system.  Obviously,  with  only  three  sources  of  power  to  spread 
to  up  to  four  user  interfaces,  cross-strapping  of  power  to  some  or  all  of  the  components  in  critical 
functions  was  a necessity.  Providing  the  visibility  and  assessment  of  the  effects  of  this  and  other 
cross-strapping  proved  to  be  the  weakness  of  the  avionic  fault  tolerance  assessment. 

The  typical  programmatic  tools  to  assess  failure  modes  and  effects  were  employed,  including  indi- 
vidual subsystem  analyses  and  some  level  of  integrated  systems  fault  testing  in  facilities  such  as 
the  Flight  Systems  Laboratory  (FSL)  and  the  Shuttle  Avionics  Integration  Laboratory  (SAIL).  Some 
fault  tolerance  escapes  were  discovered  through  the  subsystem  analysis,  and  test  programs  periodi- 
cally resulted  in  unexpected  problems  under  fault  or  off-nominal  conditions  which  could  be  cata- 
strophic if  occurring  In  flight.  These  escapes,  though  almost  all  attributable  to  the  less  than 
total  redundancy  design,  were  basically  the  result  of  the  overall  system  complexity  and  subtleties, 
which  could  hardly  be  expected  to  be  foreseen  by  the  individual  subsystem  designer  performing  his 
failure  modes  and  effects  analysis  (FMEA).  Some  of  these  factors  include  understanding  the  timing  of 
the  failures  with  respect  to  each  other  and  to  the  mission  phase,  understanding  the  software  mech- 
anization and  Its  dependence  on  time  homogeneous  data,  understanding  the  normal  and  malfunction 
procedures  which  might  be  used  by  the  crew  to  operate  the  systems  and  control  configuration,  and  fi- 
nally, understanding  the  individual  subsystem  functional  Impacts  caused  by  failures  in  the  universal 
service  subsystems. 
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FIGURE  4.-  IMVS  SELECTION  FILTER  OUTPUT  COMPARED  TO  VEHICLE  RATE  AND  SENSED  RATE. 


This  integrated  fault  tolerance  assessment  escape  mechanism  can  be  demonstrated  by  the  example 
in  figure  5.  The  FCS  muscle  for  control  during  early  entry  stages  Is  provided  by  the  aft  RCS  jets. 
These  jets,  unlike  other  flight  control  effectors,  employ  single-string  authority  for  jet  firing, 
relying  on  the  quantity  of  jets  to  satisfy  the  FO/FS  requirement.  The  FCS  avionic  interface  to  fire 
these  jets  is  provided  by  the  reaction  jet  driver  (RJD)  circuits,  which  are  divided  Into  four  chan- 
nels with  each  channel  receiving  dual  power  inputs  from  the  three-string  EPD  system  such  that  any  two 
failures  can  disable  only  two  of  the  four  RJD  channels.  The  Instrumentation  monitoring  of  the  RJD/ 
jet  system  is  provided  In  only  two  signal  conditioning  units;  however,  each  one  contains  Isolated  in- 
ternal modules  and  each  box  receives  dual  power  inputs  from  the  three-string  EPD  system  such  that  any 
two  failures  can  disable  only  half  of  the  instrumentation  system.  In  like  manner,  the  data  management/ 
command  interface  is  a four-channel  system  with  identical  redundancy  to  the  serviced  RJD's  (including 
power  redundancy).  Taken  piece  by  piece,  the  flight-critical  function  of  RCS  jet  control  appears  to 
be  FO/FS  and  each  subsystem-level  FMEA  would  support  that  conclusion.  On  closer  inspection  from  an 
integrated,  functional  end-to-end  viewpoint,  with  software  performance  considered,  it  becomes  obvious 
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that  the  fault  tolerance  is  not  completely  FO/FS,  because  of  the  channelization  of  the  EPD  inputs 
to  each  subsystem  element.  As  can  be  seen  in  figure  5,  if  the  aft  local  power  buses  A and  C were 
lost,  the  total  power  to  half  of  the  RCS  control  circuitry  would  be  lost  (RJD's  1A  and  2A),  along 
with  their  respective  data  management  interfaces  (MDM's  FA3  and  FA4) . Through  cross-strapping, 
the  remaining  half  of  the  RCS  jets  would  be  normally  sufficient  to  control  the  vehicle.  The  total 
system  reaction  to  the  loss  of  buses  A and  C,  however,  includes  loss  of  the  instrumentation  sub- 
system's signal  conditioner  0L2,  which  happens  to  provide  service  to  the  RCS  jets  controlled  by 
RJO  2B,  resulting  in  unresponsive  data  monitoring  of  those  jets.  The  RM  software  will  respond  to 
this  situation  by  recognizing  the  communications  fault  in  strings  3 and  4 and  suspending  processing 
of  those  strings.  The  signal  conditioning  fault  in  string  2,  however,  is  not  discernible  from  actual 
low  value  data  response  to  the  RM,  thereby  leading  to  a failed  "leaking"  and/or  failed  "OFF"  conclu- 
sion by  the  RM.  Either  of  these  events  results  in  a deselection  of  the  affected  jets,  with  the  final 
result  being  that  the  FCS  muscle  for  the  two  bus  failures  is  cut  to  a single  set  of  jets  which  cannot 
maintain  vehicle  control. 


LIA,  LIU,  LIL 
RIA,  RIU,  RIR 
L5D,  L5L 


L3A,  L3D,  L3L 
R3A,  R3D,  R3R 
R5D,  R5R 


L2U,  L2D,  L2L 
R2U,  R2D,  R2R 


L4U,  L4D,  L4L 
R4U,  R4D,  R4R 


FIGURE  5.-  AFT  RCS  CHANNELIZATION  ESCAPE. 


The  loss  of  two  power  buses  in  a basic  three-bus  system  is  obviously  a low-probability  situa- 
tion. It  is,  however,  required  to  be  addressed  in  assessment  of  an  FO/FS  requirement  and  is  the  rea- 
son for  the  multiple  cross-strapping  schemes  on  the  Shuttle.  As  this  and  other  specific  escapes  from 
the  FO/FS  requirement  were  discovered  in  test  facilities  and  flight  environments  with  failures  actu- 
ally present,  the  potential  for  further  unknown  escapes  in  a system  as  complex  as  the  Shuttle 
hardware/software  system  became  painfully  obvious.  The  limitations  of  resources  to  perform  actual 
verification  tests  for  every  combination  of  failures,  under  every  critical  mission  phase,  with  every 
version  of  hardware  and  software  to  be  flown,  with  every  reasonable  crew  procedural  response,  and 
with  every  reasonable  variation  of  flight  environments  are  equally  as  painful.  Recognizing  this  prob- 
lem, the  Shuttle  Program  established  an  "Avionics  Audit"  task  to  "perform  a study  and  analysis  that 
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identifies  the  fault  tolerance  capability  of  the  integrated  Orbiter  avionics  with  respect  to  func- 
tional authority  or  influence  derived  from  hardware  channelization,  hardware  cross-strapping,  soft- 
ware cross-strapping,  control  points,  crew  procedures,  and  external  environments."*  This  ongoing  task 
has  been  funded  for  more  than  SI  000  000  directly  with  unestimable  program  costs  associated  with 
study  management  and  review  and  hardware  and  software  changes  resulting  to  date. 


As  previously  implied,  FO/FS  implementation  through  a five-string  approach  would  architecturally 
eliminate  essentially  all  of  this  type  of  escape.  Lacking  that  luxury,  programs  as  complex  as  the 
Shuttle  avionics  must  establish  high-priority  activities,  such  as  FMEA's  and  sneak  circuit  analyses, 
and  integrated  end-to-end  functional  fault  analysis,  such  as  the  avionics  audit,  early  in  the  design 
phases  of  the  program  to  develop  a confident  position  from  which  to  claim  conformance  with  that 
program's  fault-tolerance  requirements. 


OTHER  LESSONS  LEARNED  IN  RM  EVOLUTION 


Similar  to  the  painful  evolution  experienced  with  the  RM  SF  interaction  with  the  FCS  perform- 
ance, a major  area  of  potentially  avoidable  RM  change  activity  resulted  because  of  hardware  perform- 
ance definitions  not  being  mature  early  enough  to  allow  adequate  RM  design.  A primary  example  of 
this  problem  is  the  RCS  RM.  Propellant  leaks  in  an  RCS  jet  can  result  in  hazardous  operation, 
thereby  requiring  fault  monitoring  and  reconfiguration  by  RM  to  preclude  further  use  of  a leaking 
jet.  RCS  hardware  design  provided  for  a temperature  measurement  on  the  oxidizer  and  fuel  valves  on 
each  jet  and  an  initially  proposed  RM  algorithm  which  would  declare  a jet  as  leaking  when  either  tem- 
perature fell  below  48°  F.  Vacuum  chamber  testing  of  actual  hardware  later  provided  a better  defini- 
tion of  the  jet  thermal  responses  to  various  leak  conditions  and  allowed  the  RM  thresholds  to  be 
adjusted  in  software  to  30°  F to  minimize  false  alarms  and  still  provide  adequate  hazard  protection. 
Flight  experiences  in  the  early  STS  missions  provided  the  final  environmental  operation  assessment, 
which  revealed  still  another  hardware  performance  sensitivity  and  required  further  RM  software 
adjustments.  It  was  determined  that  the  upfiring  primary  jets  experienced  a significant  cooling  ef- 
fect in  the  early  stages  of  entry  where  the  "g"  field  holds  the  postfiring  "dribble"  propellant  in 
the  jet  and  the  near-vacuum  environment  enhances  the  cold-inducing  evaporation/sublimation  of  that 
propellant.  This  phenomenon  actually  resulted  in  several  false  alarm/deselects  on  early  missions 
where  jets  were  relatively  cool  before  reentry,  resulting  In  a software  change  to  provide  an  even 
lower  fault  detection  limit  and  minimize  the  false  alarms.  Another  erroneous  original  assumption 
which  guided  RCS  RM  design  was  that  the  large  primary  jets  would  respond  to  leaks  In  the  same  fashion 
as  the  smaller  vernier  jets.  Again,  vacuum  testing  of  actual  hardware  under  leak  conditions  provided 
the  surprise  that  the  vernier  jets  could  not  leak  enough  to  provide  for  sufficient  cooling  effects  to 
ever  reach  the  limits  established  for  the  primary  Jets.  The  resulting  RM  change  to  account  for  this 
hardware  performance  characteristic  Included  RM  software  mods,  heater  thermostat  setting  changes, 
crew  procedural  impacts,  and  flight  usage  restrictions  based  on  vernier  Jet  warmup  sufficient  to 
ensure  RM  leak  protection.  The  problems  evidenced  by  experiences  such  as  these,  although  not  totally 
avoidable,  do  point  out  the  need  to  develop  as  completely  as  possible  the  hardware  performance  charac- 
teristics under  true  flight  conditions  before  fixing  the  associated  RM  schemes.  Lacking  that  luxury, 
modification  Impact  could  be  minimized  by  implementation  schemes  which  Include  as  much  flexibility  as 
can  be  afforded,  such  as  separate  I-loadable  limits  for  each  data  Input  to  an  algorithm. 

A second  area  of  continuing  RM  design  modification  and  assessment  is  the  dilemma  of  providing 
the  best  fault  protection  thresholds  possible  while  not  allowing  any  significant  chance  of  a false 
alarm.  A key  factor  in  this  dilemma  is  the  3a  program-established  variation  to  be  allowed  in  hard- 
ware and  system  performance.  This  implies  that  RM  should  not  declare  an  LRU  failed  that  is  within  3a 
of  the  "normal"  performance,  and  further  that,  since  -3a  is  as  good  as  +3a,  actual  differences  be- 
tween usable  LRU's  must  allow  for  somewhat  more  than  3a  (statistically  reasonable  to  assume  /?  x 3a). 
Accounting  for  this  type  of  variation  and  arbitrarily  selecting  a design  goal  to  have  no  more  than 
one  false  alarm  in  500  missions  (the  approximate  original  number  of  missions  in  the  Shuttle  Program), 
the  fault  detection  thresholds  can  be  significantly  large  so  as  to  mask  some  LRU  failures  and/or  re- 
sult in  system  errors  or  transients  that  can  jeopardize  mission  performance.  Determination  of  the 
smallest  acceptable  thresholds  to  minimize  false  alarms  while  providing  adequate  fault  detection  is 
another  late-blooming  product  due  to  the  necessity  to  have  statistically  accurate  performance  as- 
sessments. This  involves  not  only  certifiable  LRU  standard  deviation  data  but  also  development  of 
accurate  vehicle  systems  and  flight  profile  environments.  Although  this  development  task  Is  not  eas- 
ily hurried  or  readily  avoidable,  some  potential  areas  for  minimizing  the  dilemma  do  exist.  Premium 
dollars  in  the  LRU  design  and  production  phase  could  result  In  the  guaranteed  3a  variation  of  some 
LRU's  being  significantly  smaller.  Indeed,  the  exact  same  hardware  design  could  sometimes  be 


Contract  Change  Authorizations  892  and  1032  to  NASA  Contract  9-14000,  Schedule  A. 


9 


"improved  upon"  by  simply  paying  for  screening  and  documentation  of  its  quality.  A variation  of  this 
theme  could  be  to  establish  a set  of  thresholds  based  on  periodic  monitoring  and  verification  of  the 
actual  variation  of  the  flight  hardware.  One-sigma  deviations  are  considerably  more  normal  in  the 
Shuttle  hardware  performance  to  date,  and  thresholds  based  on  more  realistic  variations  could 
obviously  be  tighter  so  as  to  improve  system  performance  while  maintaining  the  same  realistic  false 
alarm  sensitivity.  The  final  solution  is,  of  course,  to  provide  five-string  operation  as  previously 
described,  thereby  eliminating  the  requirement  for  fault  detection  and  the  dilemma  of  protection 
thresholds  versus  false  alarms. 


EVOLUTION  OF  SHUTTLE  AVIONICS  FAULT  TOLERANCE  - LESSONS  LEARNED 


IMU  REDUNDANCY  MANAGEMENT 

The  lessons  learned  for  IMU  RM  have  occurred  mainly  in  three  areas:  (1)  understanding  the  hard- 

ware and  its  failure  modes  and  error  characteristics;  (2)  understanding  the  design  of  the  software 
and  its  ability  to  attenuate  errors  and  protect  against  transients;  and  (3)  making  the  software  con- 
formable to  variations  in  mission  plans,  flight  rules,  or  crew  procedures.  Key  facets  of  these  prob- 
lem areas  are  sunmiarized  in  table  1. 

TABLE  1.-  LESSONS  LEARNED  - IMU  REDUNDANCY  MANAGEMENT  OVERVIEW 


Area 

Problem 

Hardware 

• 

Error  modeling,  failure  modes 

t 

Warmup  transients,  trending,  aging 

§ 

Heading  sensitivity 

• 

Single-point  failures 

t 

BITE  use,  performance,  sensitivity 

Software 

t 

Threshold  formulation,  queuing,  resetting 
Dilemma  resolution,  lack  of  FO/FS 

• IMU  redundant  gyro  BITE  use 

• Strapdown  rate-gyro  use 

• 

• 

Transient  protection,  velocity  and  attitude 
selection  filter  design 

• Velocity  downmode  transients 

• Attitude  dithering 

Flight  operations 

t 

Extended  launch  holds 

• 

Early  al inement/delayed  entry 

t 

Computer /LRU  reconfiguration 
• Freeze-dried  GPC 
t Commfaulted  LRU's 

Three  gimbaled  IMU's  supply  velocity  and  attitude  data  to  the  airborne  computers,  which  have  the 
ability  to  automatically  detect  and  isolate  up  to  two  mission-critical  failures.  Setting  thresholds 
as  bounds  for  normal  or  acceptable  performance  has  been  one  of  the  critical  software  design  tasks. 
Setting  thresholds  below  the  envelope  of  normal  measurement  error  can  lead  to  nuisance  false  alarms 
and  premature  loss  of  an  IMU.  Allowing  for  normal  or  expected  divergence  in  measurement  error  can 
lead  to  transients  when  changing  from  the  use  of  one  IMU  to  another,  as  well  as  to  degraded  system 
performance  before  isolation  of  the  second  failure. 

To  avoid  or  minimize  these  difficulties,  selection  filters  (operating  at  either  6.25  or  1 hertz, 
according  to  need)  are  used  to  protect  against  hardover  failures,  to  control  switching  transients, 
and  to  inhibit  or  attenuate  error  growth  before  isolation  of  the  second  failure.  Tracking  tests  are 
used  for  failure  detection  and  isolation  (FDI)  at  a background  rate  of  0.0625  hertz  to  protect 
against  soft  performance  failures.  To  guard  against  a wrong  identification  in  the  event  of  a tran- 
sient error  condition,  an  IMU  can  be  permanently  failed  only  after  a number  (n-count)  of  successive 
identical  fault  identifications  occur  in  consecutive  passes  of  the  fault  identification  logic. 
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USE  OF  BITE 


Without  adequate  failure-to-noise  margins,  it  is  unreasonable  to  expect  failure  isolation  by 
means  of  software  tests.  To  avoid  this  difficulty,  BITE  is  used  as  the  f irst-priority  discrimination 
after  detection  of  a failure  in  a pair  of  IMU's.  If  BITE  does  not  discriminate,  the  software  isola- 
tion tests  are  used  to  identify  the  failed  IMU.  Use  of  BITE  in  this  manner  avoids  the  possibility  of 
BITE  false  alarms  causing  premature  loss  of  an  IMU  whose  attitude  and  velocity  measurements  continue 
to  be  good.  Also,  software  tests  are  vulnerable  to  wrong  isolation  decisions  when  exposed  to  simulta- 
neous multiaxis  failures  - failures  of  the  kind  most  often  isolatable  by  BITE  (a  tumbling  platform, 
for  example). 

If  a fault  remains  unidentified  after  a given  number  of  consecutive  fault  detections,  an  IMU  di- 
lemma is  signaled  to  the  crew  to  indicate  the  need  for  manual  intervention. 


FAILURE  MODES 

The  software  design  was  conceived  to  detect  and  identify  soft  bias  shifts  in  attitude  or  veloc- 
ity outputs.  One  of  the  great  fears  was  to  falsely  detect  errors  and  downmode  good  units,  which  was 
recognized  as  an  easy  way  to  catastrophe.  Part  of  this  fear  was  also  detection,  identification,  and 
reconfiguration  which  could  occur  for  a transient  error  condition  which  was  conceivable  for  a light- 
ning strike  or  temporary  communications  failures  in  a data  bus  link  between  the  IMU's  and  the  gen- 
eral-purpose computers  (GPC's),  hence  the  use  of  an  n-counter  logic. 

These  concerns  basically  have  led  to  a design  that  is  tolerant  of  system  noise.  During  STS-6, 
5000vig  noise  was  evident  on  the  IMU  3 z-axis  accel erometer  during  the  entire  flight.  The  noise  was 
as  high  as  30  OOOug,  evidenced  by  the  velocity  underlimit  (VUL)  BITE  alarms  during  entry.  This  IMU 
was  a good  navigator  and  was  used  almost  exclusively  for  attitude  reference  during  STS-6. 

Because  the  noise  was  contained  only  on  the  one  z-axis  accelerometer,  IMU  3 would  have  been  most 
likely  deselected  for  a threshold  violation.  If  the  noise  were  correlated  to  other  axes,  the  result- 
ing error  could  resemble  a simultaneous  multi  axis  failure.  The  danger  here  is  that,  for  the  two-level 
IMU  case,  a unit  could  be  deselected  based  on  random  error  with  a small  but  real  risk  that  a good 
unit  could  be  removed  and  the  noisy  unit  could  remain  in  candidacy.  Although  an  observant  crew  could 
manually  deselect  the  offending  unit,  procedures  for  trapping  a noisy  unit  are  being  investigated. 


SOFTWARE 

Although  we  had  confidence  software  could  be  designed  to  handle  failures  in  two  IMU's  and  obtain 
FO/FS  performance  in  three  IMU's,  the  coverage  of  failure  rate  is  not  100  percent  in  a pair  of  IMU's. 
The  BITE  coverage  is  on  the  order  of  90  percent  of  the  failure  rate.  Of  the  remaining  10  percent, 
the  software  coverage  is  on  the  order  of  60  to  80  percent  at  best,  giving  a total  coverage  of  96 
to  98  percent  of  the  failure  rate  for  the  hardware/software  system.  Although,  in  theory,  we  could 
achieve  99.8  percent  of  the  mission-critical  failure  rate  of  300.4  x 10"®  failures  per  operating 
hour,  operational  considerations  such  as  extended  holds  or  delayed  entry  can  reduce  coverage. 

Lack  of  100-percent  FO/FS  coverage  in  IMU  RM  has  led  to  reliance  on  other  available  sensors  espe- 
cially for  attitude  during  entry  where  a two-case  dilemma  could  be  catastrophic  for  a hard-failure 
condition.  A body-mounted  RGA  supplying  instantaneous  body  rate  to  flight  control  is  used  to  inte- 
grate and  maintain  an  inertial  body-attitude  state  during  a two-case  IMU  attitude  dilemma,  thus 
creating  an  artificial  fourth  IMU  for  attitude.  The  maintenance  of  the  integrated  fourth  IMU  atti- 
tude state  from  RGA  data  does  not  result  in  an  inertial  quality  attitude  reference.  Although  the 
RGA's  produce  a good  instantaneous  body  rate,  noise  and  quantization  result  in  an  inferior  inte- 
grated attitude  state  (e.g.,  approximately  70°  per  hour  effective  drift  rate).  The  addition  of  a 
fourth  IMU  could  eliminate  the  risk  of  the  IMU  RM  system  defaulting  to  the  RGA's  forever  dilemma  as 
well  as  simplify  the  design  of  the  IMU  attitude  selection  filter  and  attitude  processor. 

Differentiating  IMU  attitude  data  to  supply  a quality  body  rate  to  flight  control  could  poten- 
tially eliminate  the  need  for  the  rate-gyro  assembly  and  the  complexities  of  selection  filtering  of 
the  body  rate  data.  Refinements  in  the  software  area  include  integrating  and  maintaining  a separate 
quaternion  of  body  attitude  from  each  IMU  for  flight  control.  Quaternion  averaging  could  eliminate 
attitude  dithering  between  prime  selected  IMU's.  Averaging  could  also  provide  performance  enhancement 
and  open  up  the  tight  margins  that  now  exist  between  mission  performance  requirement  and  instrument 
capability. 

Because  performance  of  the  guidance,  navigation,  and  control  (GN&C)  system  is  degraded  when 
errors  escape  detection,  the  propagation  of  second  failure  errors  has  received  considerable  atten- 
tion. Everyone  is  aware  that  the  effects  of  a first  failure  in  three  IMU's  can  be  avoided.  Everyone 
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knows  performance  degradation  cannot  easily  be  avoided  when  one  IMU  in  a pair  fails.  Although  prime 
selecting  a unit  in  a pair  for  measurement  can  avoid  ill  effect  in  half  the  failure  cases,  there 
exists  the  intolerable  risk  of  having  selected  a failing  unit  and  having  to  absorb  the  full  impact  of 
a failure  in  the  GN&C  system.  Averaging  measurements  in  a pair  can  cut  the  error  exposure  in  half  be- 
tween the  time  of  inception  of  a failure  and  the  time  of  final  system  reconf iguration.  For  threshold 
violations,  immediate  deselection  of  an  element  of  the  pair  based  on  BITE  status  can  further  reduce 
failure  effects,  leaving  a residual  problem  of  error  propagation  for  a failed  unit  tracking  just 
below  the  threshold.  To  do  a good  job,  the  RM  designer  must  be  given  an  error  allowance  or  margin  be- 
tween normal  measurement  error  and  system  performance  requirements.  The  alternatives  are  to  accept 
the  degraded  performance  or  to  have  more  IMU's. 

The  lesson  learned  here  is  that  FO/FS  in  three  strings  requires  tightening  up  on  instrument 
error  specifications  so  that,  even  in  the  degraded  mode  before  isolation  of  the  second  failure,  the 
worst  performance  is  still  within  the  acceptable  system  performance  envelope.  This  lesson  would  be 
an  important  consideration  for  an  autonomous  onboard  navigation  system  where  three  or  four  high- 
accuracy  IMU's  could  limit  error  without  the  need  for  outside  manual  intervention  by  the  crew  or 
flight  controllers. 

One-hundred-percent  FO/FS  probably  cannot  be  achieved  in  three  IMU's.  The  problem  with  three 
strings  is  after  losing  one,  there  are  only  two  left.  No  matter  how  much  thought  is  given  to  fail- 
ure, a new,  unanticipated  and  unmodeled  failure  lurks  around  the  next  corner.  That  failure  is  the 
next  two-string  dilemma:  the  next  dragon  to  be  slain. 


THRESHOLD  FORMULATION 


In  most  instances,  values  for  the  isolation  threshold  are  set  at  20  percent  above  the  noise  enve- 
lope generated  by  the  McDonnell -Dougl as  Monte  Carlo  studies.  The  detection  thresholds  are  set  at  the 
highest  value  which  still  protects  the  GN&C  system  from  IMU  errors  that  cause  violation  of  mission 
ground  rules,  operational  constraints,  or  vehicle  safety  limits.  Sensitivity  studies  by  Rockwell  In- 
ternational -Downey  were  used  to  set  the  detection  thresholds. 


ASCENT  THRESHOLDS 

The  onboard  IMU  RM  software  in  combination  with  the  IMU  hardware  BITE  will  detect  and  identify 
the  first  IMU  failure  during  ascent.  It  will  allow  up  to  a 50-ft/sec  velocity  error  at  main  engine 
cutoff  (MECO)  before  detection  of  a second  IMU  failure  but  it  may  not  be  able  to  identify  the  failed 
IMU. 


Ground-based  flight  control  personnel  will  be  prepared  to  identify  a second  failure  by  comparing 
the  IMU  navigation  states  against  the  navigation  state  derived  from  ground-based  radar  tracking  data. 
An  onboard  state  vector  update  is  planned  during  ascent  if  the  predicted  onboard  velocity  error 
should  violate  a 40-ft/sec  MECO  constraint,  which  is  the  orbital  maneuvering  system  (OMS)  fuel  budget 
for  an  abort-to-orbit  in  event  of  a MECO  underspeed. 

During  ascent,  there  is  no  margin  between  detection  requirements  and  instrument  performance  at 
the  two-level.  An  adequate  margin  for  100-percent  probability  of  isolation  of  a second  failure  re- 
quires a ratio  of  2 for  VC0NS2/VC0NS6  for  optimal  skewing.  The  ratio  is  only  slightly  greater  than 
one  for  the  I -load  values.  Onboard  dilemmas  will  occur  for  accelerometer  failures  between  5000Mg  and 
16  500 Ug. 

A mean  acceleration  error  of  6000Pg  will  violate  the  50-ft/sec  MECO  velocity  accuracy  targeting 
constraint  for  jettison  of  the  external  tank.  Delta-V  averaging  at  the  two-level  will  attenuate  a ve- 
locity bias  by  one-half  so  the  range  of  failure  dilemmas  that  potentially  must  be  isolatable  by 
ground-based  personnel  is  from  12  OOOPg  to  16  500ug. 


ON-ORBIT  THRESHOLDS 

Normal  instrument  performance  for  platform  alinement  and  drift  will  not  support  mission  accuracy 
requirements  without  frequent  IMU  realinements,  yet  there  is  a necessity  to  allow  extended  periods 
for  the  crew  to  sleep.  The  I-load  values  for  the  on-orbit  attitude  detection  thresholds  are  set  to 
allow  a 10-hour  sleep  period  before  potential  false  alarms  can  occur  at  the  three-level  (8  hours  for 
two  IMU's).  The  detection  threshold  will  ramp  above  the  attitude  requirement  for  a safe  entry  2.5 
hours  after  alinement.  After  this  time,  ground  personnel  must  be  prepared  to  call  for  a realinement 
(if  the  actual  IMU  attitude  divergence  should  exceed  the  attitude  error  constraint  for  a safe  entry) 
to  maintain  capability  for  a safe  return  in  event  of  a contingency  deorbit. 
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For  a protected  entry,  IMU  realinement  must  occur  no  earlier  than  2 hours  before  entry  interface 
or  2.5  hours  before  TACAN  acquisition.  Earlier  alinements  result  in  loss  of  second  failure  coverage 
during  entry. 

The  100-ft/sec  altitude  rate  error  requirement  at  TACAN  acquisition  requires  that  velocity  tilt 
error  transmitted  to  navigation  be  no  more  than  1350  arc-seconds  during  entry.  The  two-IMU  detection 
threshold  ceiling  (VC0NS8)  is  set  to  protect  this  requirement. 


ENTRY  THRESHOLDS 

IMU  RM  can  detect  and  isolate  both  a first  and  a second  IMU  failure  during  entry,  allowing  errors 
up  to  100  ft/sec  in  altitude  rate  at  TACAN  acquisition  for  the  second  failure  with  one  notable  excep- 
tion: if  the  second  IMU  failure  is  a dual-axis  failure  in  the  ambiguous  direction  and  not  covered  by 
BITE,  then  there  is  potential  for  dilemma  at  the  two-level. 

The  velocity  isolation  threshold  (VRAMP2)  is  queued  by  a manual  operation  by  the  crew.  The 
value  of  VRAMP2  assumes  the  crew  will  PRO  to  MM  304  5 minutes  before  entry  interface  (El).  If 
the  crew  delays  the  PRO  until  El,  the  20-percent  margin  over  instrument  noise  disappears.  If 
the  PRO  occurs  later  than  El,  there  is  a danger  of  false  isolation  during  entry. 

The  altitude  rate  uncertainty  should  not  exceed  100  ft/sec  during  blackout.  The  3a  altitude 
rate  error  due  to  navigation,  atmosphere,  and  winds  is  48  ft/sec.  The  RM  community  chose  to  allow 
approximately  85  ft/sec  error  in  altitude  rate  due  to  IMU  failures.  There  are  two  ways  to  look 
at  this  error: 

1.  The  budget  is  the  requirement  minus  3a  Nav  in  RSS  sense, 
h = [loo2  - 482]  !/2  = 87  ft/sec 

2.  The  budget  is  the  requirement  minus  la  Nav  in  an  additive  sense, 
li  = [lOO  - 16]  = 84  ft/sec 


IMU  RM  LAUNCH  HOLD  CONSTRAINTS 


A greater  launch  hold  capability  is  needed  to  avoid  potential  launch  delays  resulting  from  IMU 
alinement  accuracy  limitations.  Present  baseline  flight  software  and  I-loads  were  designed  to  sup- 
port a safe  entry  for  an  abort  once  around  (AOA)  given  a 3a  vendor  specification  IMU  for  which  the 
preflight  gyrocompass  alinement  was  completed  50  minutes  before  lift-off. 

Present  flight  rules  result  in  a nominal  countdown  time  line  with  30  minutes  between  completion 
of  the  alinement  and  lift-off.  The  nominal  time  line  provides  a 10-minute  planned  hold  at  T-20  (just 
before  the  OPS  9/1  transition).  This  hold  does  not  affect  the  IMU's  because  the  preflight  alinement 
programs  are  scheduled  so  that  the  alinement  process  continues  during  the  hold.  Platform  release 
occurs  at  the  OPS  9/1  transition  at  T-20  minutes  in  the  count.  A second  planned  hold  of  10  minutes 
is  scheduled  at  T-9  minutes,  yielding  the  30  minutes  between  platform  release  and  lift-off. 

For  the  case  of  3a  IMU's,  the  Shuttle  flight  software  IMU  RM  I-loads  allow  a maximum  time  of  110 
minutes  between  platform  release  and  lift-off.  Because  30  minutes  of  this  time  is  spent  in  the  nomi- 
nal count,  80  minutes  are  available  for  unplanned  holds.  Because  flight  IMU's  are  rarely  3a  and  their 
relative  performance  can  be  monitored  by  flight  controllers,  much  longer  holds  may  be  possible  based 
on  the  real-time  prelaunch  performance.  Up  to  4 hours  may  be  available  between  platform  release  and 
lift-off  based  on  past  performance. 

In  any  event,  beginning  100  minutes  from  platform  release,  flight  controllers  are  required  to 
identify  all  IMU  failures  at  the  two-level  because  the  flight  software  no  longer  has  this  capability. 
Second  failure  identification  capability  is  not  restored  again  until  the  first  on-orbit  alinement. 

Platform  misalinement  can  be  predicted  analytically  based  on  expected  initial  misalinement  and 
nominal  gyro  drift  at  platform  release: 

Equation  (1)  Up  error  = RSS  (60,  0.02915  J\)  arc-seconds 

Equation  (2)  North  or  West  error  = RSS  (20,  0.0094  T2)  arc-seconds 

where  is  time  in  seconds  from  completion  of  gyrocompass ing  and  T2  is  the  time  in  seconds  from  com- 
pletion of  the  VEL_TILT  subroutine. 
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Here,  the  North,  West,  and  Up  coordinates  are  topodetic  and  are  frozen  at  the  instant  of  plat- 
form release.  This  epoch  North,  West,  Up  frame  is  labeled  (N0,  W0,  U0).  After  platform  release,  the 
true  topodetic  North,  West,  Up  frame  (N.  W,  U)  will  be  rotating  at  Earth  rate  compared  to  the  iner- 
tial IMU  frame  or  the  epoch  (N0,  W0,  U0)  frame.  To  find  the  expected  IMU  misalinement  about  North, 
West,  Up  at  lift-off,  it  is  first  necessary  to  calculate  the  expected  IMU  error  in  N0,  W0,  U0  coordi- 
nates and  then  to  transform  this  result  to  the  N,  W,  U frame  at  lift-off.  Table  2 snows  the  final 
launch  misalinement  as  transformed  for  the  effect  of  Earth  rotation  rate.  The  earth  rotation  rate 
carries  the  vertical  axis  error  into  the  West  axis.  (For  a level  IMU  on  the  Equator,  the  vertical 
axis  would  point  West  6 hours  after  platform  release.)  Knowledge  of  platform  misalinement  at  lift- 
off allows  the  use  of  nominal  dispersion  analysis  sensitivities  for  predicting  navigation  state  error 
at  MECO  or  at  points  of  interest  along  the  AOA  reference  mission  profile. 

TABLE  2.-  IMU  MISALINEMENT  AT  LAUNCH  FOR  INCREASING 
HOLD  TIME  IN  OPS  101  (la) 


Time 

Hr  Min 

North , 
sec 

West, 

sec 

Up, 

sec 

RSS, 

sec 

LEVEL, 

sec 

0 

0 

20 

20 

63 

69 

28 

20 

24 

28 

79 

86 

37 

40 

33 

43 

99 

113 

54 

1 

60 

45 

64 

124 

146 

78 

80 

61 

88 

147 

182 

107 

100 

79 

117 

167 

219 

141 

2 

120 

99 

148 

184 

256 

178 

140 

120 

179 

196 

292 

216 

160 

145 

213 

205 

330 

258 

3 

180 

172 

247 

209 

366 

301 

200 

203 

381 

208 

405 

347 

220 

236 

314 

204 

443 

393 

4 

240 

270 

348 

194 

481 

440 

The  analytically  derived  IMU  misalinement  can  be  used  to  predict  the  time  of  violation  of  the 
IMU  RM  attitude  threshold,  thereby  estimating  the  available  unplanned  hold  time.  Table  2 shows  the 
misalinement  of  a single  la  IMU  for  the  first  4 hours  after  completion  of  the  preflight  alinement. 

The  table  shows  the  misalinement  about  North,  West,  and  Up,  the  RSS  of  the  three  misalinements 
(labeled  RSS),  and  the  RSS  of  the  two-level  errors  (LEVEL).  At  2 hours,  the  RSS  misalinement  is  256 
arc-seconds  la.  For  a pairwise  IMU  tracking  test,  the  parity  equation  residual  would  be  expected  to 
be  /?  x 256  or  362  arc-seconds  la.  The  3a  misalinement  would  be  expected  to  be  1086  arc-seconds. 

The  two-level  attitude  fault  detection  threshold  is  1138  arc-seconds  as  defined  in  the  current 
flight  software  I-loads.  (The  threshold  half-angle  of  2.76  x 10~3  radian  is  stored  in  AC0NS5,  MSID 
V97U4215C.)  A 3a  IMU  pair  would  be  expected  to  violate  the  two-level  fault  detection  threshold  just 
beyond  2 hours  from  platform  release.  These  data  are  plotted  in  figure  6,  which  shows  the  expected 
pairwise  tracking  test  errors  for  la,  2 a,  and  3a  IMU  pairs  compared  to  the  two-level  attitude  fault 
detection  threshold.  A 3a  IMU  pair  would  intercept  the  threshold  126  minutes  after  platform  release. 

It  should  be  noted  that  IMU  misalinements  are  not  completely  observable  by  ground  monitoring. 
Flight  controllers  observe  total  relative  misalinement  between  pairs  of  IMU's  and  azimuth  misaline- 
ment Is  not  observable  by  ground  navigation  performance  analysis.  Hence,  launch  hold  performance 
constraints  must  be  based  in  part  on  results  of  premission  simulations. 
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FIGURE  6.-  PRELAUNCH  I MU  DRIFT  MISALINEMENTS. 


MEASUREMENT  RE  DUNE 

Protecting  the  threshold  against  false  alarms  implies  the  observed  instrument  error  is  below 
the  threshold  after  making  allowance  for  observation  errors.  The  measurement  error  bound  can  be 
estimated  analytically.  The  granularity  of  the  display  is  0.01  deg/axis  and  the  measurement  error 
can  be  no  more  than  0.01  deg/axis  about  three  axes  or  0.017°.  The  Mission  Control  Center  algorithms 
compute  pairwise  IMU  errors  using  functions  of  gimbal  angles  the  readout  quantization  of  which  is  20 
arc-seconds  per  axis,  and  the  expected  measurement  error  would  be  no  less  than  20  arc-seconds  about 
eight  axes  of  two  four-gimbal  platforms  or  0.0157°  (RSS  of  20  taken  eight  times).  An  additional 
error  of  65  arc-seconds  is  budgeted  for  the  resolved  errors  and  gimbal  pivot  misalinement  which  shows 
up  during  the  post-lift-off  tower-clear  roll  maneuver  as  observed  in  Monte  Carlo  simulations  of  the 
ascent  flight  profile. 


An  IMU  performance  redline  is  established  as  follows: 


The  threshold  0.316° 
Less  measurement  error  0.017° 
Less  tower-clear  roll  error  0.018° 


Limit  line  0.281° 


This  limit  line,  plotted  in  figure  6,  is  violated  by  a 3<*  IMU  pair  111  minutes  after  platform  re- 
lease. 
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MCC  MONITORING  OF  EXTENDED  HOLDS 


Because  the  RM  threshold  could  possibly  be  violated  at  80  minutes  into  a hold,  the  Flight  Opera- 
tions Directorate  decided  to  monitor  relative  performance  to  protect  the  threshold  knowing  they  could 
terminate  an  unplanned  hold  earlier;  otherwise,  the  program  would  continue  the  present  baseline  which 
allows  90  minutes  of  unplanned  hold. 


VELOCITY  UNDERLIMIT  BITE 

The  loss  of  IMU  velocity  output  is  one  area  of  software  transient  protection  that  is  not  ade- 
quately covered.  The  current  understanding  of  the  failure  mode  is  that  all  three  accelerometer 
counters  freeze.  The  IMU  SOP  will  then  output  the  accelerometer  bias  calibration  terms  only. 
Therefore,  wrong  isolations  or  dilemma  can  occur. 

The  VUL  BITE  was  designed  to  detect  the  loss  of  velocity  output.  The  VUL  BITE  is  the  only  BITE 
that  compares  one  IMU  against  another  in  order  to  make  a decision.  The  VUL  BITE  uses  the  compensated 
delta  velocities  to  perform  the  test  so  the  frozen  counters  are  masked  by  the  compensation  terms. 

This  test  works  only  in  acceleration  environments  greater  than  60  OOOug  (i.e.,  not  during  OPS  2)  and 
the  test  is  limited  to  IMU's  having  accel erometer  bias  calibration  terms  less  than  50  OOOug.  Comm- 
faulted  IMU's  are  not  excluded  from  this  test.  The  crew  select/deselect  switch  determines  the  test 
candidacy.  If  a loss  of  velocity  output  occurs  when  the  VUL  BITE  is  disabled,  a dilemma  or  wrong  iso- 
lation will  occur  because  of  the  large  accelerometer  bias  compensations. 

A solution  to  this  problem  is  to  check  the  uncompensated  velocity  counts  for  each  IMU.  The  re- 
vised VUL  BITE  test  would  then  be  performed  at  a rate  such  that  the  smallest  accelerometer  bias  com- 
pensation term  yields  at  least  one  count. 

If  the  sum  of  the  squares  of  the  velocity  counts  for  all  three  axes  is  less  than  three,  the 
counters  have  frozen  and  that  IMU  has  a VUL  failure.  This  test  assumes  that  the  velocity  counter  bit 
toggling  will  cause  at  most  one  count  per  axis  during  the  period  of  consideration.  This  proposed  VUL 
BITE  test  is  valid  during  all  flight  phases.  The  only  problem  with  the  revised  BITE  is  that  tran- 
sient BITE  false  alarms  can  occur  if  the  environment  exactly  matches  the  accelerometer  bias  compensa- 
tion terms.  The  revised  VUL  BITE  test  was  felt  to  be  an  expensive  software  change  and  the  community 
was  willing  to  accept  the  loss  of  failure  coverage  (ref.  6). 


VELOCITY  SELECTION  FILTER  RECTIFICATION  TRANSIENTS 


Another  area  of  inadequate  software  transients  protection  is  In  the  velocity  selection  filter. 
The  velocity-data-good  logic  was  designed  to  protect  navigation  from  large  constant  IMU  failures. 
However,  during  STS-3  on-orbit,  a new  IMU  failure  mode  was  observed  (ref.  7).  IMU  3 experienced  a 
large  transient  bias  shift  (34  750Ug)  followed  by  a smaller  constant  accelerometer  bias  (500vg).  If 
this  failure  had  occurred  at  the  two-IMU  level,  the  selection  filter  would  have  correctly  performed 
the  temporary  downmode  to  the  one-IMU  level  for  the  duration  of  the  transient.  If  the  transient  had 
occurred  between  rectification  cycles,  navigation  would  have  experienced  the  full  effect  of  the  tran- 
sient (ref.  8). 

One  solution  to  the  problem  of  transients  polluting  navigation  is  to  exclude  temporarily  de- 
selected IMU's  from  the  selection  filter  until  a new  set  of  rectification  biases  has  been  computed. 
Deselected  IMU's  refer  to  commfaulted  IMU's  or  any  temporarily  downmoded  IMU  due  to  a velocity-data- 
good  violation.  This  procedure  will  prevent  the  transient  from  polluting  the  selected  velocity  and 
thus  the  single-string  navigation.  Currently,  a crew-reselected  IMU  is  treated  in  this  manner.  How- 
ever, this  solution  does  not  protect  the  entry  three-string  navigation  since  it  does  not  use  the 
selected  velocity.  The  ground  support  console  operators  will  have  to  monitor  the  three  navigated 
states  to  protect  navigation  from  transients. 

This  solution  has  been  approved  for  software  implementation  as  CR  59308A  on  release  2X/XX. 


FLIGHT  TIME-LINE  IMU  RM  EFFECTS 


The  values  of  the  IMU  RM  fault  detection  and  isolation  thresholds  are  a function  of  certain  mis- 
sion events.  The  attitude  thresholds  ramp  from  either  OPS  9/1  transition  (platform  release)  or  on- 
orbit  alinements.  The  velocity  thresholds  are  constant  before  lift-off,  jump  to  a higher  value  dur- 
ing ascent,  and  drop  to  a low  value  until  MM  304  (entry  interface  minus  5 minutes).  At  MM  304,  the 
velocity  thresholds  begin  to  ramp  until  a high  constant  value  is  reached.  The  threshold  values  were 
determined  by  instrument  performance,  guidance  constraints,  and  IMU  platform  skewing  geometry. 
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The  velocity  thresholds  are  insensitive  to  mission  time-line  changes  since  the  triggering  events 
always  occur  at  roughly  the  same  times.  However,  time-line  changes  are  critical  to  the  attitude 
thresholds  since  they  are  reset  at  each  on-orbit  alinement.  The  attitude  fault  detection  threshold 
ramps  to  a constant  value  while  the  fault  isolation  threshold  continues  to  ramp.  Consequently,  after 
about  5 hours,  all  two-IMU  level  attitude  failure  coverage  is  lost  (fig.  7).  The  attitude  thresholds 
were  set  based  on  the  last  onboard  alinement  occurring  approximately  70  minutes  before  the  deorbit 
burn.  The  attitude  RM  covered  about  60  percent  of  all  failures  not  covered  by  BITE.  (BITE  covers 
about  90  percent.) 


FIGURE  7.-  TWO-IMU  LEVEL  ATTITUDE  FAILURE  COVERAGE. 


Before  STS-4,  it  was  decided  to  perform  the  last  onboard  alinement  one  revolution  earlier  than 
on  previous  flights  (165  minutes  before  the  deorbit  burn)  to  ease  the  crew  workload.  Unfortunately, 
this  decision  caused  a degradation  of  the  two-IMU  level  attitude  failure  coverage.  (See  fig.  1.)  The 
Entry  Flight  Techniques  Panel  decided  to  leave  the  time  line  alone  If  there  are  three  good  IMU's.  If 
there  are  only  two  good  IMU's  In  the  system,  the  last  onboard  alinement  will  be  performed  70  minutes 
before  the  deorbit  burn,  as  It  was  done  previously  (ref.  9). 

The  other  flight  time-line  attitude  threshold  concern  Is  for  a one-revolution-late  deorbit.  All 
two-IMU  level  attitude  failure  coverage  will  be  lost  before  touchdown  (ref.  10).  In  this  case,  an 
IMU-to-IMU  alinement  should  be  performed  about  70  minutes  before  the  deorbit  burn. 

The  entry  attitude  threshold  criteria  preclude  changing  the  values  without  degrading  the  RM  cov- 
erage even  further.  Since  the  IMU's  have  been  behaving  well  on  orbit  and  during  entry  for  the  first 
six  flights,  it  may  be  possible  to  reevaluate  the  la  drifts  and  lower  the  thresholds,  thus  regaining 
RM  attitude  coverage. 
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ABSTRACT 

The  decision  to  use  a programmable  digital  control  system  on  the  Space  Shuttle  engine 
was  a new  application  of  digital  control  in  the  early  1970's.  The  use  of  digital 
control  was  primarily  based  upon  the  need  for  a flexible  control  system  capable  of 
supporting  the  total  engine  mission  on  a large  complex  pump  fed  engine.  The  mission 
definition  included  all  control  phases  from  ground  checkout  through  post  shutdown 
propellant  dumping. 

The  flexibility  of  the  controller  through  reprogrammable  software  allowed  the  system 
to  respond  to  the  technical  challenges  and  innovation  required  to  develop  both  the 
engine  and  controller  hardware.  This  same  flexibility,  however,  placed  a severe 
strain  on  the  capability  of  the  software  development  and  verification  organization. 

The  overall  development  program  required  that  the  software  facility  accomodate  signi- 
ficant growth  in  both  the  software  requirements  and  the  number  of  software  packages 
delivered. 

The  above  requirements  became  a serious  challenge  to  the  software  devel  opment  faci  1 i ty . 
This  challenge  was  met  by  reorganization  and  evolution  in  the  process  of  developing 
and  verifying  software.  The  resulting  process  consistently  provided  high  quality 
software  on  schedule  throughout  the  balance  of  the  shuttle  program. 

INTRODUCTION 

In  March,  1972,  NASA  selected  the  Rocketdyne  Division  of  Rockwell  International  to 
design  and  develop  the  Space  Shuttle  Main  Engine  (SSME)  for  the  reusable  Space  Shuttle. 
The  engine  development  program  was  managed  by  NASA/Marshall  Space  Flight  Center  (MSFC) 
and  was  supported  by  various  engineering  laboratories  within  the  Science  and  Engin- 
eering Directorate. 

A digital  computer  control  concept  was  selected  as  the  basis  of  the  engine  control 
system.  Digital  control  was  selected  over  the  more  classical  engine  control  concepts 
of  valve  sequencing  or  analog  computer  control  because  of  the  following  advantages. 

The  engine  was  still  in  the  early  stages  of  development  and  the  digital  controller 
allowed  modified  operational  sequences  and  functional  changes  through  software  up- 
dates. Time  consuming  and  costly  controller  hardware  modification  could  be  avoided  as 
the  engine  matured.  The  concept  of  software  modification  provided  flexibility  and 
adaptability  during  all  stages  of  the  engine  development  and  use. 

The  digitally  based  systems  also  demonstrated  the  most  economic  means  of  providing 
fast  and  flexible  control  and  sophisticated  monitoring  and  redundancy  management 
schemes  for  the  complex  operational  sequence  of  the  engine. 

The  above  attributes  of  the  system  were  reflected  in  the  requirements  for  a software 
development  and  test  facility  which  could  respond  quickly  and  accurately  to  the  needs 
of  a dynamic  engine  development  program.  The  initial  organization  defined  for  this 
facility  had  previously  demonstrated  iteself  as  being  effective  for  the  typical 
embedded  software  program  in  a digital  controller.  The  magnitude  and  scale  of  soft- 
ware development  required  for  the  Main  Engine  Program  soon  made  it  evident  that  the 
"classical"  organization  was  not  up  to  the  task. 

The  following  paragraphs  describe  the  early  problems  and  the  solutions  developed  to 
provide  the  required  quality  software  needed  to  support  the  engine  development  prog- 
ram . 
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DISCUSSION 


EARLY  HISTORY  AND  CHALLENGES 

The  initial  organization  defined  for  the  software  development  was  as  shown  in  Figure 
1.  This  organization  was  typical  for  an  embedded  software  program  delivered  with  a 
hardware  unit  in  the  early  1970's. 

The  software  group  had  a vertical  organization  for  design  coding  and  testing  of  soft- 
ware programs.  Requirements  were  from  two  sources:  the  controller  hardware/sof tware 

relationships  from  the  project  systems  group;  and  the  engine  system  software  needs 
from  the  customers  software  requirements  specification.  The  organization  had  a strong 
knit  team  approach  and  was  staffed  with  experienced  software  designers  who  had  the 
background  to  efficiently  develop  and  test  a software  program.  This  approach  had 
generally  worked  and  was  cost  effective  on  the  embedded  software  programs  delivered  in 
previous  control  system  applications. 

The  organization  appeared  to  fit  the  program.  The  initial  design  definition  was  going 
to  lead  to  the  Flight  Configuration.  The  controller  hardware  being  developed  was  the 
projected  flight  control  configuration  and  there  was  only  one  defined  deliverable 
software  configuration. 

The  major  challenges  recognized  relative  to  the  controller  software  at  this  time  were: 

1.  The  engine  being  developed  was  the  most  complex  high  performance 
engine  ever  built.  Due  to  its  high  operating  pressures,  temperatures 
and  turbopump  speeds  very  precise  and  rapid  control  of  critical  engine 
functions  were  of  prime  importance. 

2.  Failure  of  a control  function  during  engine  hot  fire  development 
testing  could  result  in  catastrophic  damage.  The  system  hardware 
was  redundant  to  provide  safety  against  failure.  The  software, 
however,  was  identical  in  the  redundant  channels  of  the  controller. 

A software  error  that  was  fatal  in  the  first  channel  would  also  be 
present  in  the  second  channel. 

The  above  requirements  dictated  a conservative  software  design  with  significant 
amounts  of  selfchecking  and  the  ability  to  respond  rapidly  to  a control  perturba ti on . 

It  was  also  recognized  that  this  software  would  require  extensive  testing  and  veri- 
fication prior  to  use  in  an  engine  hot  fire  situation. 

The  philosophy  on  the  testing  was  to  do  three  levels  of  test.  The  first  at  the  soft- 
ware module  level  using  a host  machine.  The  second  at  the  software  sys tern  veri  f i cati  on 
level  in  the  controller  hardware  while  the  hardware  was  linked  to  a hybrid  simulation 
of  the  engine  and  vehicle  interfaces.  The  final  testing  was  to  be  performed  at  the 
NASA  Marshall  Hardware  Simulation  Laboratory  where  the  software  again  in  the  cont- 
roller hardware  was  verified  with  an  engine  simulation  containing  the  actual  engine 
control  sensors  and  actuators. 

This  overall  test  philosophy  proved  to  be  correct  and  remained  throughout  the  software 
program  development  stages. 

There  was  a third  and  significant  challenge  to  the  software  development.  This  chall- 
enge was  not  initially  recognized  for  either  its  scope  or  magnitude.  The  problem 
evolved  from  one  of  the  significant  advantages  of  using  the  programmable  digital 
controller.  The  control  system  allowed  relative  inexpensive  flexibility  in  accomod- 
ating changes  in  the  engine  and  associated  control  scheme.  This  led  to  a staged 
evolution  of  the  overall  system  development.  Innovative  changes  to  the  engine  system 
could  be  planned  and  implemented  without  schedule  loss  due  to  controller  modifications. 

The  difficulty  was  in  the  demand  this  placed  on  the  software  development  and  veri- 
fication operations.  The  changes  and  evoluation  required  ever  increasing  software 
growth  in  program  size  and  sophistication.  This  had  been  anticipated  but  the  actual 
growth  was  between  100  to  200%  over  early  projections.  The  growth  was  primarily  due 
to  the  fact  that  as  the  engi ne/controll er  system  matured  it  was  recognized  that  a 
more  efficient  and  sophisticated  control  capability  could  be  accomodated  by  the  basic 
digital  control  concept.  The  most  severe  demand  on  the  software  development,  however, 
was  due  to  the  fact  that  engine  development  dictated  a controller  and  associated 
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software  be  available  from  the  earliest  stages.  The  early  availability  need  resulted 
in  a semi -hardened  controller  hardware  design  and  placed  the  rapid  change  requirements 
on  the  software.  This  was  further  aggrevated  as  both  the  engine  systems  and  the  cont- 
roller hardware  definition  changed  as  the  engine  matured.  The  above  created  an 
incremental  or  multilevel  approach  to  the  engine  testing  and  resulting  controller 
software  needs. 

Reasonable  progress  on  the  program  dictated  that  there  would  be  several  iterations  of 
both  the  engines  configuration  and  engine  controllers  as  we  progressed  to  the  final 
operational  stage.  These  iterations  had  changing  and  or  conflicting  software  require- 
ments. Also  several  versions  of  the  software  configurations  were  required  simultan- 
eously to  service  the  various  engine  test  stands  and  development  laboratories. 

The  above  scenario  resulted  in  the  requirement  of  simultaneous  development,  testing 
and  maintenance  of  two  to  three  basic  versions  of  the  operational  software  in  the 
same  facility  with  the  same  technical  staff.  Each  basic  version  of  the  software  had 
20  to  30  revisions  which  required  verification,  certification  and  shipment. 

The  realities  of  the  situation  soon  made  it  evident  that  the  software  organization  was 
not  meeting  the  immediate  or  long  term  needs  of  the  controller  program  or  the  engine 
development  program. 

The  initial  concept  of  software  development  could  not  handle  the  environment.  We  saw 
a degradation  of  the  quality  of  the  software  documentation  and  numerous  errors  in  the 
shipped  versions  of  software.  Serious  cost  overruns  and  schedule  slips  developed. 
There  was  a growing  concern  we  would  provide  software  that  coul d result  in  a catas- 
trophic engine  failure. 

DEVELOPED  SOLUTION 

The  basic  problem  with  the  existing  organization  was  that  it  had  not  been  structured 
to  handle  the  large  software  development  operation  required  to  deliver  and  maintain 
simultaneously  several  software  definitions  for  a single  target  control  system. 

The  problem  was  reviewed  and  broken  down  into  the  following  elements: 

1.  Organization:  The  software  design,  development  and  test 

responsibilities  had  been  organized  as  a tight  knit  team  with 
overlapping  and  fuzzy  responsibilities.  The  group  worked  well 
on  a typical  single  string  embedded  software  development  but 
was  inefficient  for  the  large  embedded  program  requiring  multi- 
ple simultaneous  program  design  cycle  iterations. 

Their  was  a need  for  a better  definition  of  the  responsi- 
bilities and  interface  between  the  Systems  group  and  the 
Software  Design  group.  Software  Design  was  accepting  direction 
from  both  the  customer  through  the  Customer  Software  Require- 
ments Specification  and  from  Systems  through  the  Controller 
Systems  Requirements  Specification.  This  direction  at  times 
conflicted  or  overlapped  due  to  the  different  stages  of  engine 
system  and  controller  development. 

2.  Change  Control  : Software  requirements  were  changing  rapidly. 

Change  and  problem  control  were  not  rigidly  documented  and  became 
suspect  when  the  volume  of  changes  and  problems  increased.  The 
test  plan  or  test  tracking  system  defined  could  not  handle  the 
heavy  volume  of  test  and  retest  that  was  building  up  on  the  pro- 
gram. The  software  design  documentation  specification  structure 
was  formalized  and  specific  but  the  above  problems  caused  this 
documentation  to  degrade  significantly  in  both  its  accuracy  and 
the  ability  to  meet  shipping  schedules. 

3.  Qua  1 i ty  Control : There  was  a need  for  an  independent  group 

identified  to  review  and  pass  on  the  accuracy  or  quality  of  the 
software  or  its  progress  throughout  the  design  process.  Quality 
was  left  to  the  individual  designers  for  their  portion  of  the 
effort.  Although  the  individual  effort  was  good,  the  continuity 
across  the  program  was  missing  and  overall  quality  suffered. 
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4.  Management : The  design  process  had  grown  so  complex  and 

large  that  even  though  individuals  in  the  organization  felt 
that  they  were  accomplishing  their  tasks  currently  and  report- 
ing to  be  on  schedule,  the  overall  development  was  missing  all 
of  the  major  milestones.  The  problem  was  isolated  to  the  fact 
that  intermediate  check  points  or  gates  in  the  design  process 
were  non-exi s tant . The  designers  did  not  understand  they  had  a 
problem  until  the  last  step  which  was  to  test  their  design, 
against  a program  requirement,  in  the  verification  test  facil- 
ity. 

The  above  reviews  and  problem  identification  resulted  in  a reorganization  of  the  soft- 
ware development  groups  and  the  development  process.  The  reviews  identified  that  the 
environment  of  the  project  required  multiple  software  programs  in  various  stages  of 
maturity  to  be  in  the  development  pipeline  simultaneously. 

The  software  development  was  reorganized  by  borrowing  from  the  structures  and  docu- 
mentation requirements  that  had  been  proven  for  multiple  phase  hardware  development 
cycles.  Specifically  the  development  was  changed  to  break  the  overall  process  up  into 
smaller  operations  which  could  be  identified  and  managed  independant  of  the  proceed- 
ing or  following  operation.  Completion  criteria  and  control  documentation  was  then 
identified  for  each  of  the  operations.  These  changes  allowed  the  tracking  and  manage- 
ment of  the  multiple  programs  in  process. 

The  software  development  was  reorganized  as  shown  in  Figures  1 and  3.  This  organiza- 
tion provided  solutions  to  the  specific  problems  we  had  identified  in  the  previous 
paragraphs.  Originally  it  was  felt  that  the  change  in  organization  and  added  controls 
would  significantly  increase  the  cost  of  the  operation,  however,  after  some  evolution 
and  refinement  this  organization  proved  to  be  able  to  deliver  higher  quality  software 
and  software  documentation  at  a comparable  cost  and  always  on  schedule. 

Referring  to  Figure  2,  it  can  be  seen  that  the  new  organization  contained  two  new 
groups,  Test  and  Reliability.  Also  the  roles  of  Systems  and  Software  Design  were 
modified  to  fit  the  concept  of  the  software  development  facility  operating  as  a soft- 
ware factory  or  production  line. 

The  reorganization  and  the  addition  of  several  procedures  and  methods  did  not  signi- 
ficantly change  the  overall  functions  performed  during  the  software  development.  The 
changes  were  intended  to  break  the  overall  development  of  the  process  into  manageable 
and  traceable  subunits  with  definitive  completion  criteria.  Each  subunit  process  had 
a controlled  source  of  incoming  information  and  in  turn  became  the  controller  source 
of  incoming  information  for  the  next  step  of  the  process. 

The  following  paragraphs  will  describe  the  changes  that  were  made  and  the  problems 
that  were  solved  by  these  changes. 

Systems  Design 

The  Systems  design  group  was  identified  as  the  primary  customer  interface.  All  cust- 
omer direction  and  software  design  requirements  flowed  through  the  systems  group. 

This  provided  a focal  point  for  the  design  requirements  definition  for  the  various 
software  packages  being  developed.  The  above  procedures  provided  a unified  and  cont- 
rolled interface  between  the  software  process  and  the  customer  and  hardware  needs  and 
revisions. 

The  second  significant  change  relative  to  the  system  group  was  that  they  were  given 
the  responsibility  for  the  generation  of  the  Verification  Test  Requirements  for  the 
software.  This  document  defined  the  test  or  retest  required  for  a base  program  or  for 
a revision.  Generation  of  these  documents  significantly  improved  the  quality  of  the 
software  testing.  The  software  was  not  tested  against  a design  requirement  and  not 
the  software  design  interpretation  of  the  requirement. 

Systems  was  also  given  the  respons i bi 1 i ty  of  defining  the  retest  required  against  a 
given  operational  program  if  that  program  was  revised  and  updated.  The  organization 
now  had  all  external  interfaces  and  software  requirement  documentation,  both  design 
and  test, focused  in  one  group.  This  change  eliminated  the  earlier  conflicting  require- 
ments and  definitions  from  reaching  the  design  floor.  The  Systems  group  integrated 
all  design  and  test  requirements  into  documents  they  controlled  and  maintained,  the 
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software  designers  and  software  testers  could  work  to  a single  consistent  source  of 
direction. 

Software  Design 

The  Software  Design  group  was  also  reorganized  to  provide  a process  which  had  small 
identifiable  design  steps  that  the  process  development  could  progress  through.  These 
steps  were  designed  such  that  completion  of  a given  step  or  function  was  identifiable 
and  had  a testable  criteria  for  completion.  The  Software  Design  process  now  included 
the  detail  design,  code  and  walk  through  of  the  design,  testing  of  the  design  module 
and  integration  of  the  module  into  the  operational  program  as  independant  functions. 

The  functional  and  detail  design  were  provided  by  the  software  design  engineers  and 
the  changes  were  documented  via  a software  change  memo.  This  memo  identified  the 
module  being  designed  in  response  to  the  specific  design  requirements  and  also  incorp- 
orated the  new  and/or  modified  software  documentation  required  for  the  change. 

The  change  memo  was  then  used  as  the  design  print  for  coding  of  the  changes.  It  was 
also  used  as  the  document  that  directed  change  of  both  the  source  code  for  the  oper- 
ational program  and  the  program  design  documentation. 

The  software  change  memo  provided  a definite  reviewable  traceable  definition  of  a 
piece  of  the  software  design.  Although  it  required  considerable  time  and  detailing 
by  the  designer  it  allowed  the  use  of  junior  grade  engineers  and/or  technicians  to 
do  the  coding,  the  production  of  the  software  source  change  and  the  update  of  the 
source  configuration  library.  It  also  provided  a document  that  could  be  reviewed 
against  the  design  requirement  for  correctness  by  the  reliability  group.  After 
review  and  completion  of  coding  and  mark-up  of  the  redline  source  configuration,  the 
design  walk  through  was  completed.  Members  of  software  design,  software  production, 
verification  and  systems  group  used  the  walk-through  as  a vehicle  to  verify  the  code, 
met  the  design  and  the  design  met  the  intent  of  the  requirements. 

The  code  was  then  incorporated  into  the  source  and  the  module  was  tested  as  an  entity 
by  the  software  group.  It  was  then  incorporated  in  the  source  being  prepared  for  the 
test  floor  and  the  software  designer  and  coders  would  use  abbreviated  test  document- 
ation to  perform  integration  testing  of  the  change.  This  integration  testing  was  the 
final  debugging  of  the  particular  change  by  the  software  group  and  determined  if  the 
module  was  ready  to  be  handed  over  to  the  test  team  for  verification.  After  complet- 
ion of  integration  testing  the  new  test  source  program  was  presented  to  the  Verifica- 
tion Test  Group.  They  would  perform  a standard  verification  acceptance  test  of  the 
new  program.  This  standard  test  checked  the  critical  paths  and  timing  of  the  oper- 
ational programs  nad  was  the  criteria  for  acceptance  of  a new  software  version  for 
detailed  testing  on  the  test  floor. 

Verification  Test 


The  verification  testing  group  was  one  of  the  two  new  sections  created  in  the  software 
organization.  Their  responsibilities  included  the  generation  of  detailed  cookbook 
type  test  procedures  to  be  used  in  the  testing  of  the  software.  The  verification  test 
group  was  also  responsible  for  identification,  scheduling  and  control  of  all  equipment 
and  documentation  required  to  create  and  control  the  test  facility.  Their  primary 
function,  however,  was  to  perform  the  actual  verification  of  the  software  program  and 
revi si ons . 

The  verification  was  completed  as  a two  step  process.  The  first  testing  of  a new 
software  program  was  called  the  dry  run.  The  dry  run  test  purpose  was  to  identify  any 
problems  with  the  software  update  code  and  test  procedure  or  test  implementation. 
Problem  resolution  or  debugging  was  not  allowed  during  Dry  Run  Test.  When  a problem 
was  encountered  an  Internal  Software  Note  (ISN)  was  generated  and  the  testing  contin- 
ued through  the  procedure.  The  identified  problems  were  then  assigned  to  the  res- 
ponsible groups  and  worked  off  without  interrupting  the  test  flow. 

After  completion  of  Dry  Run  Testing  and  correction  of  all  identified  problems,  the 
formal  verification  testing  was  initiated.  This  formal  testing  did  not  allow  dev- 
iation from  procedures  or  expected  results.  Problems  that  occurred  during  this  test 
would  require  a formal  review  and  retest  after  correction.  No  outstanding  problem 
was  allowed  after  formal  verification  test  completion  unless  It  had  been  accepted  via 
the  customer  through  a Software  Waiver. 
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The  verification  test  group  solved  three  problems  that  had  plagued  the  earlier  develop- 
ment. These  were: 

1.  Under  the  original  organization  Software  Design  was  to  do 
their  own  verification  testing  of  the  software.  Experience 
with  that  organization  showed  that  the  designers  were  not  gen- 
erating their  test  procedures  to  verify  that  the  software  met 
the  design  requirements.  The  procedures  were  generated  to  test 
that  the  software  worked  the  way  the  software  designer  had  des- 
igned it.  The  new  organization  utilized  test  personnel  to 
generate  detailed  test  procedures  from  test  requirements  docu- 
mentation. These  detailed  cookbook  procedures  were  purposely 
generated  with  a minimum  knowledge  of  the  actual  software  des- 
ign. The  procedure  writer  used  the  software  design  documentation 
only  to  find  the  names  of  subroutines  or  data  words  required 

for  a particular  test  sequence. 

2.  The  second  problem  solved  was  the  original  organization  put 
an  unreasonable  amount  of  schedule  pressure  on  the  software 
designer.  The  designer  had  to  design,  code  and  debug  his  pro- 
grams. He  was  then  required  to  generate  a formal  test  procedure 
and  accomplish  the  verification  testing.  This  effort  did  not 
utilize  the  software  designers  major  talent  in  the  most  efficient 
manner.  He  spent  toomuch  time  generating  test  procedure  and 
performing  verification  testing  of  the  software.  The  new  organi- 
zation solved  the  problem  by  allowing  the  test  group  to  develop 
test  procedures  in  parallel  with  the  software  design  and  also 
relieved  the  software  designer  of  test  responsibility.  The  soft- 
ware design  group  could  go  on  to  the  next  design  cycle  while 

the  test  group  verified  the  current  design. 

3.  The  third  problem  solved  was  the  parallel  operation  signi- 
ficantly collapsed  the  amount  of  time  required  to  process  a change. 

Paralleling  the  design  operation  and  the  generation  of  test  pro- 
cedures provided  adequate  margin  to  allow  the  consistent  delivery 
of  software  updates  to  the  Marshall  Simulation  Laboratories  and 
the  Engine  Test  Stands. 

Software  Re  1 i abi 1 i ty 

The  final  group  in  the  new  organization  was  a small  group  of  reliability  engineers  who 
functioned  as  a product  assurance  organization  for  the  software  operation.  Their 
duties  included  review  and  approval  of  the  software  change  memos  against  the  design 
requirments.  They revi ewed  a 11  test  procedure  generation  against  the  test  requirements. 
Verified  that  all  required  documentation  updates  and  design  walk  throughs  had  been 
completed  prior  to  release  of  software  to  a source  update.  Verified  that  all  test 
paragraphs  had  been  completed  and  the  data  was  acceptable.  Identified  and  tracked  all 
open  problems  against  a source  update  through  the  use  of  Internal  Software  Notes  (ISN) 
and  the  ISN  log. 

The  Internal  Software  Note  was  the  key.  document  in  the  tracking  of  the  entire  software 
development  effort,  including  the  testing.  While  many  of  the  ISNs  are  generated  by 
the  test  teams,  they  may  be  written  by  any  member  of  any  of  the  four  groups  who  detects 
a potential  problem  in  a specification,  the  program,  a test  procedure,  a flow  chart, 
test  equipment  or  anything  else  that  may  affect  the  software  or  its  verification. 
Groundrules  are  that  only  one  problem  is  documented  on  each  ISN  and  that  every  problem, 
proposed  software  change,  procedure  chance,  etc.,  must  be  documented  in  an  ISN.  New 
ISNs  are  collected  each  day  and  are  reviewed  by  the  ISN  board. 

The  board  is  chaired  by  Reliability  and  includes  members  of  the  other  three  groups. 

They  determine  the  most  likely  cause  of  the  problem  and  assign  the  ISN  to  one  of  the 
four  groups  for  action.  At  these  daily  board  meetings  all  other  outstanding  ISNs  are 
reviewed  to  determine  if  any  are  completely  resolved  and  can  be  closed  or  should  be 
transferred  to  another  group  for  further  action.  Approval  of  all  four  groups  is 
required  to  close  an  ISN. 

Following  the  meeting,  the  additions,  changes  and  closures  are  entered  into  a computer 
program  and  an  ISN  log  is  printed  showing  all  open  ISNs  and  the  groups  responsible  for 
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action.  The  reports  highlight  the  number  of  known  problems  requiring  resolution  prior 
to  a shipment  and  any  group  that  is  developing  a significant  backlog. 

Reliability  was  tasked  with  maintaining  the  ISN  log  and  a log  on  the  status  of  open 
and  completed  testing.  Software  update  could  not  be  shipped  from  the  facility  until 
these  two  logs  had  been  closed  through  resolution  of  the  open  problems  or  a request 
for  outstanding  problem  waivers  from  Rocketdyne. 

CONCLUSIONS 

The  process  described  above  evolved  from  a need  for  extremely  reliable  software  as  a 
part  of  a critical  shuttle  control  system  and  early  difficulties  with  this  software 
development  effort.  A significant  measure  of  the  success  of  the  developed  process  is 
that  the  earlier  experienced  problems  did  not  exist  through  the  balance  of  the  dev- 
elopment program.  Since  implementing  the  process,  each  software  update  and  accompany- 
ing documentation  was  delivered  on  or  ahead  of  schedule. 

The  vast  amount  of  engine  hot  fire  time  that  the  controllers  and  the  associated  soft- 
ware have  successfully  supported  demonstrate  that  the  developed  process  has  consist- 
ently provided  high  quality  operational  programs.  Successful  completion  of  the  Shuttle 
launches  further  confirms  that  the  software  development  program  is  sound. 

It  has  been  said  that  the  real  benefit  of  our  exploration  of  space  is  not  the  explor- 
ation itself,  but  the  development  of  techniques  needed  to  manage  large,  complex 
processes  where  success  is  a must  rather  than  a goal.  The  development  of  this  software 
design  system  is  a case  in  point  of  the  above  statement.  The  key  elements  of  this 
success  --  planning,  organization,  tracking  and  discipline  are  applicable  to  all  soft- 
ware processes.  The  concept  of  distinct  groups  with  well  defined  responsibilities, 
periodic  status  reviews,  documentation  control  approvals  and  reviews,  a formal  track- 
ing procedure  and,  providing  authority  consistent  with  responsibility,  are  not  unique 
in  their  application  to  the  SSMEC  program.  The  need  for  these  elements  of  their 
effective  implementation  was  learned  through  experience  on  the  program.  The  real 
benefit  from  this  experience  is  the  continued  use  of  these  concepts  on  future  software 
development  and  verification  programs. 


25 


MAIN  ENGINE  CONTROLLER 
INITIAL  ORGANIZATION 


FIGURE  1 


CUSTOMER 

REQUIREMENTS 

CUSTOMER  INTERFACE 

HARDWARE 

SOFTWARE 

DESIGN 

HARDWARE  REQUIREMENTS 

SOFTWARE 

CODE 

SOFTWARE  REQUIREMENTS 

HARDWARE  TEST 


SOFTWARE  TEST 


SOFTWARE  DEVELOPMENT  ORGANIZATION 


FIGURE  2 


DESIGN  SPECIFICATION 

. DETAILED  DESIGN 

. TEST  PROCEDURES 

. APPROVAL  OF; 

TEST  REQUIREMENTS 

. DOCUMENTATION 

. DEFINE  TEST 
HARDWARE 

- DESIGN  SPEC 

HARDWARE  INTERFACE 

, CODE 

. CONDUCT  TESTS 

- DETAIL  DESIGN 

CUSTOMER  INTERFACE 

. PRODUCTION 

. DOCUMENT  TESTS 

- TEST  PROCEDURES 

RETEST  DEFINITION 

. PROBLEM  RESOLUTION 

. VERIFY  TEST  RESULTS 

PROJECT  WORK  FLOW 


FIGURE  3 


REFERENCES 


1.  W.  T.  Mitchell,  "Space  Shuttle  Main  Engine  Digital  Controller",  Conference 

on  Advanced  Control  Systems  for  Aircraft  Powerplants,  Proceedings  No.  274,  North 
Atlantic  Treaty  Organization,  1979. 

2.  R.  M.  Mattox,  J.  B.  White,  "Space  Shuttle  Main  Engine  Controller",  NASA  Techni cal 
Paper  1932,  November  1981. 

3.  W.  T.  Mitchell,  R.  F.  Searle,  "SSME  Digital  Control  Design  Characteristics", 

Space  Shuttle  Technical  Conference,  NASA,  JSC,  June  28-30,  1983. 


i 


29 


^3  ' $85  -1689  2 

SHUTTLE  AVIONICS  SOFTWARE  DEVELOPMENT 
TRIALS,  TRIBULATIONS,  AND  SUCCESSES: 
THE  BACKUP  FLIGHT  SYSTEM 


Edward  S.  Chevers 

NASA  Lyndon  B.  Johnson  Space  Center 
Houston,  Texas  77058 


THE  BACKUP  FLIGHT  SYSTEM  REQUIREMENT 

The  initial  design  of  the  Orbiter  flight  control  system  was  limited  to  the  quad-redundant  com- 
puter complex.  Systems  management  and  nonavionic  functions  were  contained  in  a fifth  computer,  which 
was  not  considered  flight  critical.  This  concept  was  well  into  development  when  a blue  ribbon  panel 
was  asked  to  review  all  aspects  of  the  Approach  and  Landing  Test  (ALT)  phase  of  the  Space  Shuttle  Pro- 
gram to  verify  that  the  design  was  proper.  One  of  the  conclusions  reached  by  the  panel  was  that  an 
unnecessary  risk  was  being  taken  by  not  providing  a backup  flight  control  system  for  the  first 
flight.  This  decision  was  based  on  the  relative  complexity  of  the  computer  synchronization  scheme 
being  implemented  and  the  lack  of  a direct  manual  flight  control  capability. 

It  must  be  remembered  that  the  ALT  development  occurred  during  the  early  seventies  when  micro- 
processors as  such  did  not  exist,  only  four-bit  arithmetic  chips  were  available,  and  software  consist- 
ed mostly  of  punched  cards  implemented  in  batch  mode  on  a ground  computer.  Of  course,  man  had  gone 
to  the  Moon  in  an  Apollo  spacecraft  and  used  a digital  computer  for  navigation  and  guidance,  but 
there  was  also  an  analog  flight  control  system  onboard  with  both  automatic  and  manual  modes  avail- 
able. Beyond  that,  a manual  direct  mode  enabled  bypassing  all  the  electronics  and  powering  the  reac- 
tion jets  directly.  Thus,  the  step  forward  to  a total  computer-controlled  flight  system  was  very  sig- 
nificant and  risky  according  to  the  blue  ribbon  panel.  Therefore,  they  recommended  a backup  mode  for 
ALT. 

That  was  the  background  behind  the  decision  to  add  the  backup  flight  system  (BFS).  Initially, 
it  was  to  be  a very  simple  system  installed  for  ALT  only  and  deleted  once  confidence  had  been 
developed  in  the  primary  flight  system.  The  word  simple  is  very  important  because  one  of  the  main 
concerns  was  the  NASA  capability  to  properly  verify  the  large  software  programs  being  developed  for 
the  Orbiter.  The  development  of  the  primary  flight  system  software  is  addressed  in  a companion 
paper;  therefore,  that  area  is  not  discussed  further  here. 


THE  BFS  IN  THE  APPROACH  AND  LANDING  TEST  PHASE 

The  approach  taken  for  the  BFS  was  to  develop  a very  simple  and  straightforward  software  program 
and  then  test  it  in  every  conceivable  manner.  The  result  was  a program  that  contained  approximately 
12  000  full  words  including  ground  checkout  and  the  built-in  test  program  for  the  computer.  The 
flight  control  portion  of  the  software  consisted  of  approximately  6000  words.  The  remainder  was  for 
the  systems  management  functions,  which  still  had  to  be  performed  in  the  fifth  computer  along  with 
the  backup  autopilot  functions.  The  BFS  ALT  configuration  is  shown  in  figure  1. 

Because  of  the  relatively  simple  program  involved,  several  decisions  were  made  that  had  major  im- 
pact later  in  the  Space  Shuttle  Program.  First,  Rockwell  was  given  the  contract  for  the  BFS  and  the 
contract  was  an  amendment  to  the  vehicle  contract.  Technically,  this  arrangement  meant  that  the  BFS 
was  delivered  to  NASA  as  part  of  the  vehicle  and  not  as  an  independent  entity  like  the  primary  flight 
system  software.  This  difference  was  not  significant  in  ALT  since  the  BFS  had  a unique  set  of  hard- 
ware, the  software  program  was  small,  and  much  of  the  testing  was  done  on  the  vehicle.  During  the 
Orbital  Flight  Test  (OFT)  phase,  when  the  BFS  software  grew  to  almost  100  000  words,  it  became  very 
difficult  to  equate  the  primary  and  backup  software  verification  efforts  and  to  break  out  the  BFS 
software  as  an  independent  deliverable  product.  Second,  and  even  more  significant  with  time,  was  the 
decision  to  not  provide  a BFS  software  development  and  verification  facility  at  Rockwell.  Here  a- 
gain,  it  was  a logical  and  proper  choice  for  the  ALT  BFS  but  unsatisfactory  from  the  standpoint  of 
long-term  progranmatic  effects.  This  subject  is  addressed  later  in  discussions  concerning  the  BFS  in 
the  OFT  phase  of  the  program. 

To  perform  verification,  a series  of  tests  was  defined  using  the  actual  flight-type  hardware  and 
simulated  flight  conditions.  Then,  literally  hundreds  of  simulated  flights  were  flown  and  detailed 
performance  analysis  was  conducted.  The  intent  of  most  BFS  tests  was  to  demonstrate  that  a stable 
flightpath  could  be  obtained  after  engagement  from  an  anomalous  initial  condition.  In  fact,  the 
early  ground  rule  for  BFS  was  to  stabilize  the  vehicle  long  enough  for  the  crew  to  bail  out.  Later, 
the  importance  of  completing  the  mission  was  stressed.  Since  the  tests  did  not  have  to  run  from  sepa- 
ration to  touchdown  every  time  and  the  ALT  flights  lasted  less  than  30  minutes,  quite  often  it  was 
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FIGURE  2.-  BACKUP  FLIGHT  SYSTEM  TESTING. 


FIGURE  1.-  BACKUP  FLIGHT  SYSTEM  CONFIGURATION. 


possible  to  run  five  or  six  tests  per  hour  by  merely  changing  the  initial  conditions.  Figure  2 con- 
tains’ an  overview  of  the  tests  performed  on  the  BFS. 

With  a well-documented  set  of  requirements,  a software  program  that  was  easy  to  understand,  a 
dedicated  set  of  hardware  for  performing  tests,  and  a combined  Rockwell/NASA  team  of  less  than  50  com- 
patible people,  the  ALT  BFS  could  be  called  "the  ideal  program."  Any  proposed  changes  from  either 
Rockwell  or  the  NASA  Lyndon  B.  Johnson  Space  Center  (JSC)  had  to  be  justified.  Changes  were  not 
allowed  just  because  they  made  things  easier  or  took  less  code  or  ran  faster  in  the  computer.  A sig- 
nificant improvement  in  system  capability  and  a requirement  for  the  improvement  had  to  be  demonstrat- 
ed before  a modification  was  allowed. 

One  change  that  was  made  before  the  first  ALT  flight  was  the  technique  for  acceptance  testing  of 
the  software.  As  stated  earlier,  the  BFS  was  delivered  as  part  of  the  vehicle,  but  it  was  always 
recognized  that  separation  of  the  software  from  the  total  system  was  desirable  from  a contractual 
standpoint.  To  accomplish  this  separation,  Rockwell  combined  with  Intermetrics  in  development  of  a 
FORTRAN  simulation  of  the  BFS  that  would  run  on  a ground-based  computer.  The  program  emulated  the 
AP-101  flight  computer  and  executed  the  programs  one  minor  cycle  at  a time.  The  input  data  being 
used  in  the  emulator  and  output  commands  computed  from  these  data  were  collected  each  minor  cycle 
along  with  cycle  counts,  error  logs,  status  words,  and  other  pertinent  internal  computer  parameters. 
These  data  were  then  fed  into  buffers  in  multiplexer-demultiplexer  (MDM)  simulators  in  a Shuttle 
Avionics  Test  Set  (SATS),  which  could  be  connected  directly  to  a flight  computer.  The  flight  com- 
puter then  accessed  the  data  buffers  by  using  actual  MDM  address  codes  and  did  computations  based 
on  the  data  acquired.  The  general-purpose  computer  (GPC)  outputs  were  collected  each  minor  cycle 
and  stored  for  comparison  with  the  precalculated  results  from  the  Intermetrics  emulation  program. 

Many  will  recognize  this  technique  as  being  the  equivalent  of  the  flight  equipment  interface  de- 
vice (FEID)  used  with  the  flight  computers  in  the  JSC  Software  Development  Laboratory  (SDL).  The  pri- 
mary difference  was  that  the  BFS  technique  was  used  for  final  tape  verification  rather  than  for  soft- 
ware development.  Every  parameter  in  the  emulation  program  and  in  the  calculated  answers  was  carried 
out  to  the  full  32-bit  word  size  in  the  ground  processing  computer.  The  flight  computer  results  were 
also  dumped  as  32-bit  words,  and  complete  bit-for-bit  comparison  was  made  during  postprocessing.  Only 
the  last  2 bits  of  each  32-bit  word  were  allowed  to  be  different  before  a failure  was  noted.  This 
technique  was  the  precursor  to  the  captive  simulation  (CAPSIM)  procedure  used  by  the  BFS  for  verifi- 
cation during  the  OFT  flight  phase. 


THE  BFS  IN  THE  ORBITAL  FLIGHT  TEST  PHASE 


As  the  ALT  phase  of  the  program  neared  completion  and  attention  was  turned  to  the  OFT  phase,  sev- 
eral conditions  became  apparent.  First,  a large  portion  of  the  primary  flight  system  software  devel- 
opment for  ALT  was  unique  to  that  portion  of  the  Space  Shuttle  Program  and  could  not  be  used  during 
OFT.  Second,  a backup  flight  system  was  going  to  be  required  and  it  would  have  to  operate  during 
both  the  ascent  and  the  descent  portions  of  the  mission.  Since  some  abort  options  required  a once 
around  the  Earth  abort  or  an  abort  to  orbit  before  reentry,  navigation  and  guidance  would  have  to  be 
added  to  the  BFS.  Suddenly,  the  BFS  had  matured  to  a full  guidance,  navigation,  and  control  (GN&C) 
system  and  some  of  the  early  ALT  decisions  became  very  important.  As  indicated  by  figure  3,  the 
BFS  no  longer  Is  limited  to  a small  subset  of  dedicated  hardware.  The  BFS  GPC  is  in  parallel  with 
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FIGURE  3.-  ORBITER  102  PRIMARY/BACKUP  FLIGHT 
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FIGURE  4.-  BFS  DEVELOPMENT  AND  VERIFICATION 
TEST  LEVELS. 


the  primary  flight  system  computers  and  has  full  access  to  all  sensor  inputs  and  effector  output 
changes  after  engagement. 

As  mentioned  previously,  there  was  an  early  decision  by  both  Rockwell  and  NASA  program  manage- 
ment to  not  provide  a software  development  facility  at  Rockwell  for  the  BFS.  When  couched  in  the  con- 
text of  BFS  being  used  only  for  ALT  and  never  again,  that  decision  was  certainly  proper.  However, 
for  OFT,  there  was  a requirement  to  develop  a full-blown  BFS  with  GN&C,  systems  management  (SM), 
sequencing,  and  display  capability.  Experience  with  the  primary  flight  system  during  ALT  had 
shown  that  developing  the  primary  flight  system  software  and  the  SDL  simultaneously  was  almost 
an  unmanageable  effort.  Each  task  was  major  in  regard  to  the  number  of  highly  trained  specialists 
necessary,  and  the  level  of  management  ability  needed  was  not  available  at  the  beginning  of  the 
ALT  phase. 

Now,  the  BFS  was  faced  with  the  same  dilerrma:  how  to  bring  together  the  massive  resources 
required  to  develop  some  of  the  most  sophisticated  software  ever  attempted  while  imposing  the  most 
stringent  safety  and  reliability  specifications  ever  conceived.  Although  the  decision  may  have  been 
based  more  on  ALT  problems  than  on  pure  logical  reasoning,  it  was  decided  that  having  one  contractor 
do  all  programing  was  not  the  best  choice.  Therefore,  C.  S.  Draper  Laboratories  (CSDL)  was  selected 
to  program  the  GN&C,  Intermetrics  would  program  the  SM,  sequencing,  uplink,  and  ground  checkout 
functions,  and  Rockwell  would  program  the  operating  system,  the  displays,  and  the  overall  integra- 
tion. As  prime  contractor,  Rockwell  was  also  responsible  for  total  system  verification.  The  various 
levels  of  integration  and  verification  required  by  the  BFS  are  shown  in  figure  4.  With  the  software 
tasks  broken  into  three  approximately  equal  sized  portions,  everything  should  have  gone  along  in  par- 
allel until  it  came  together  again  at  the  end  in  a nice,  neat  package.  The  first  indication  of  trou- 
ble appeared  when  CSDL  had  to  spend  a considerable  amount  of  time  developing  their  best  guess  of  how 
the  backup  system  software  (BSS)  would  work.  This  research  was  necessary  since  much  of  the  GN&C  is 
input/output  (I/O)  oriented  and  depends  on  the  timing  established  by  the  BSS.  Intermetrics  developed 
preliminary  sequencing  codes  but  could  not  perform  any  dynamic  verification  because  most  of  the  se- 
quences were  dependent  on  guidance  and  navigation  events  for  which  programing  had  not  been  done  by 
CSDL.  Rockwell  could  not  spend  full  time  on  the  BSS  because  most  of  their  time  was  spent  resolving 
integration  problems  among  all  three  sections  of  the  software.  In  addition,  JSC  began  asking  Rockwell 
for  their  system  integration  and  verification  plan  and  the  issue  of  software  validation  was  drawing 
increased  attention. 

It  was  in  this  time  frame  that  the  CAPSIM  technique  became  a predominant  feature  in  BFS  verifi- 
cation. The  technique  was  similar  to  the  emulation  program  used  in  ALT  but  was  revised  to  use  actual 
code  to  generate  the  output  data  for  the  comparison  program.  Precalculated  inputs  were  used  as  drivers 
and  placed  in  the  input  compools  or  buffer  areas  of  the  computer.  The  GN&C  and  sequencing  code  accessed 
these  inputs  and  performed  their  minor  cycle  computations.  Output  results  including  actuator  com- 
mands and  display  signals  were  then  put  into  output  compools,  where  the  data  were  collected  and 
stored  on  tape.  All  of  this  was  done  at  CSDL  using  actual  GN&C,  sequencing,  and,  later,  SM  flight 
code,  but  still  with  the  CSDL  version  of  the  operating  system.  The  other  limitation  was  in  use  of 
the  CSDL  statement  level  simulator  (SLS),  which  is  a non-real-time  development  tool  and  thus  would 
not  detect  marginal  timing  conditions  or  dynamic  interactive  timing  problems  between  different  soft- 
ware modules.  The  CAPSIM  data  generator  procedure  is  depicted  in  schematic  form  in  figure  5. 
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FIGURE  5.-  CAPSIM  DATA  GENERATION. 


The  next  step  was  to  Integrate  the  Draper,  Intermetrics,  and  Rockwell  portions  of  software  into 
a single  load  tape  for  verification  at  Downey.  Computer  test  sets  and  mass  memory  units  were  not 
available  for  general-purpose  use;  therefore,  a test  set  tape  was  made  that  could  be  loaded  into  the 
flight  computer  from  a SATS  unit.  The  tape  format  was  tailored  to  the  requirements  of  the  specific 
computer  in  the  SATS;  therefore,  the  test  set  tape  was  different  from  the  final  mass  memory  load  tape 
which  would  be  required  at  JSC.  With  the  flight  computer  loaded  and  cabled  to  the  SATS,  the  opera- 
tional BFS  was  ready  for  the  simulated  input  data  from  the  CAPSIM  program,  and,  as  anticipated,  opera- 
tion was  not  smooth  initially.  The  evaluation  procedure  involved  collecting  the  output  buffer  data 
each  minor  cycle  from  the  flight  computer  and  then  comparing  the  tabulated  data  with  equivalent  data 
sets  from  the  CSDL  tests. 

Approximately  25  test  points  in  ascent  and  20  in  descent  were  selected  for  comparison.  Continu- 
ous comparison  was  not  possible  at  first  because  no  automated  plotting  programs  were  available.  These 
programs  were  developed  after  6 to  8 months  of  the  effort  and  later  included  dual  comparison  on  the 
same  plot.  If  all  of  this  history  seems  archaic,  remember  that  the  BFS  started  from  scratch  and  had 
to  compete  with  the  primary  system  for  resources  and  time  on  any  existing  facilities.  During  the 
first  6 months  of  CAPSIM  testing,  the  BFS  was  a virtual  basket  case.  When  output  data  were  compared, 
there  were  times  when  it  was  impossible  to  determine  whether  they  were  from  the  same  program.  One  of 
the  main  problems  consisted  of  the  initial  condition  values  used  at  CSDL  and  Rockwell.  The  guidance 
and  navigation  programs  were  very  sensitive  to  the  data-base  parameters,  and  as  many  as  five  or  six 
different  versions  could  exist  at  any  given  time  in  the  various  JSC,  CSDL,  and  Rockwell  facilities. 

The  problem  is  not  major  in  terms  of  gross  performance  of  the  flight  system,  but  when  two  different 
facility  tests  were  overlayed  and  every  discrepancy  had  to  be  accounted  for,  a considerable  amount  of 
time  was  wasted  in  trying  to  explain  away  what  could  be  a minor  difference.  Of  course,  in  the  begin- 
ning, no  one  was  sure  whether  a minor  difference  was  insignificant  or  an  indication  of  a potential 
major  software  coding  problem. 

With  time,  as  everyone  began  to  get  a better  feeling  for  the  differences  in  output  results  and 
more  of  the  process  became  automated,  dual  comparisons  between  the  BFS  and  the  primary  flight  system 
also  were  begun.  One  of  the  cost-saving  features  of  BFS  verification  was  the  so-called  "piggyback" 
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mode  of  operation,  in  which  the  BFS  was  to  use  all  applicable  data  from  the  primary  flight  system  and 
eliminate  duplication.  The  results  of  one  test  case  showed  very  close  correlation  between  the  pri- 
mary and  the  backup  systems  and  both  were  found  to  be  wrong.  The  problem  would  not  have  had  a major 
impact  on  the  flight  but  did  serve  to  show  the  danger  in  not  performing  total  independent  analysis. 
Afterwards,  the  BFS  people  were  careful  to  spot  check  more  test  cases  and  to  perform  some  independent 
analysis. 

Although  the  CAPSIM  technique  was  the  primary  verification  tool  for  the  BFS,  it  did  have  one  se- 
rious shortcoming.  The  test  case  scenarios  were  from  a cataloged  set  of  runs  at  CSDL  which  had  been 
based  on  primary  flight  system  testing.  Again,  this  procedure  was  in  accordance  with  direction  to 
control  development  cost  and  maximize  use  of  existing  primary  flight  system  information.  The  concern 
that  arose  was  based  on  the  fact  that  the  BFS  would  only  be  engaged  after  a massive  primary  flight 
system  failure.  Therefore,  the  initial  conditions  could  quite  possibly  be  at  the  limits  of  the  nor- 
mal primary  GN&C  boundary  conditions  and  very  few  BFS  test  runs  were  made  from  these  very  abnormal 
conditions.  Therefore,  approximately  100  additional  "stress  cases"  were  developed  to  be  run  in  the 
Flight  Simulation  Laboratory  (FSL)  in  Downey  and  the  Shuttle  Avionics  Integration  Laboratory  (SAIL) 
at  JSC.  By  combining  multiple  objectives  into  one  test  run,  the  final  number  of  individual  test 
runs  was  refined  to  37.  Every  one  of  these  tests  was  unique  and  required  special  downlist  data 
formats  for  additional  visibility,  and  all  data  analysis  was  manual.  Since  these  tests  were  to 
be  performed  one  time  as  a final  safety  verification  check  before  the  first  OFT  flight,  automated 
data  processing  could  not  be  justified.  All  but  a few  of  these  tests  were  performed  successfully, 
and  failure  of  the  few  was  due  to  procedural  errors  or  to  a misunderstanding  of  the  intent  of 
the  stress  condition.  However,  adequate  data  were  collected  to  give  the  Shuttle  community  a high 
level  of  confidence  in  the  capability  of  the  BFS  to  meet  its  intended  objectives  for  the  first 
orbital  flight. 

Some  of  this  confidence  waned  on  launch  day,  when  the  BFS  failed  to  synchronize  with  the  primary 
flight  system  a few  hours  before  lift-off.  However,  the  shock  to  the  BFS  developers  quickly  disap- 
peared when  it  was  determined  that  the  problem  was  due  to  a timing  error  in  the  primary  system  and 
that,  in  fact,  the  BFS  recognized  the  problem  and  was  trying  to  inform  the  launch  team  that  an  anoma- 
ly existed.  When  the  problem  was  identified  and  fully  analyzed,  it  was  shown  that  the  mission  could 
have  been  flown  successfully  even  with  the  interface  timing  error.  The  BFS  would  have  bypassed  the 
data  being  sent  in  the  wrong  time  slot  and  corrected  itself  after  engagement  had  that  been  necessary. 
However,  those  facts  were  not  available  for  several  days  after  the  launch.  A modification  was  made, 
the  flight  was  highly  successful,  and  considerable  relief  was  expressed  by  all  involved.  The  primary 
flight  system  people  said  they  knew  all  along  the  BFS  would  not  be  needed  but  were  glad  it  was  there. 
The  BFS  people  said  they  knew  they  were  ready  to  take  over  and  save  the  mission  but  were  glad  they 
did  not  have  to  do  it. 


CONCLUDING  REMARKS 


The  BFS  has  never  been  required  to  demonstrate  its  capability.  A proposed  on-orbit  engagement 
and  orbital  maneuvering  system  (OMS)  engine  burn  has  now  been  deleted  from  the  list  of  flight  test 
requirements.  This  change  is  partly  the  result  of  a very  full  and  busy  flight  plan  and  partly  of  the 
high  confidence  level  which  exists  in  the  capability  of  the  BFS  to  perform  when  required.  Although 
most  of  the  people  who  worked  on  the  backup  flight  system  would  like  to  see  it  used,  I consider  it  a 
supreme  compliment  from  the  Program  Office  and  the  Flight  Directors  to  accept  the  system  on  the  faith 
of  the  development  and  verification  program.  This  acceptance  is  a tribute  to  the  people  and  organi- 
zations who  put  so  much  of  themselves  into  the  project  for  many  years. 


SUMARY 


In  retrospect,  several  factors  or  lessons  learned  in  the  BFS  evolution  stand  out  prominently. 
Neither  the  NASA  nor  anyone  else  should  ever  attempt  to  develop  a software  program  approaching 
100  000  words  in  size  without  having  the  development  facilities  in  place,  especially  when  the  require- 
ment is  for  zero-defect  software  code.  In  addition  to  the  basic  facility,  the  software  analysis  and 
support  tools  should  be  available  throughout  the  project,  not  near  the  end.  It  will  always  be  diffi- 
cult to  convince  a program  manager  that  he  should  put  a sizable  amount  of  his  money  into  a facility 
initially  for  the  purpose  of  saving  money  several  years  downstream.  But  no  NASA  or  contractor  pro- 
gram manager  should  again  have  to  experience  the  trials  and  tribulations  that  existed  for  the  primary 
flight  system  in  ALT  and  the  backup  flight  system  in  OFT.  In  the  end,  the  only  glory  is  in  success. 
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FLIGHT  SOFTWARE  FAULT  TOLERANCE  VIA  THE  BACKUP  FLIGHT  SYSTEM 


Terry  D.  Humphrey  and  Charles  R.  Price 
NASA  Lyndon  B.  Johnson  Space  Center 
Houston,  Texas  77058 


ABSTRACT 

A generic  software  error  in  the  quadruply  redundant  primary  flight  system  could  result  in  the 
catastrophic  loss  of  Space  Shuttle  vehicle  control  in  the  hostile  environment  of  ascent  or  reentry. 
The  Space  Shuttle  backup  flight  system  was  designed  to  protect  the  crew  and  vehicle  in  this  eventual- 
ity. The  significant  challenges  met  in  the  design  and  development  of  this  state-of-the-art  protec- 
tive system  is  the  subject  of  this  paper. 


INTRODUCTION 


Implementation  of  the  backup  flight  system  (BFS)  for  the  Space  Shuttle  is  a major  advance  in 
state-of-the-art  fault-tolerant  software  in  general  and  in  Space  Shuttle  fault-tolerant  flight  soft- 
ware in  particular.  The  BFS  was  chartered  to  protect  against  a software  fault  in  the  most  sophisti- 
cated flight  software  system  ever  implemented:  the  Space  Shuttle  primary  flight  software  (PFS).  The 

PFS  is  designed  to  operate  a redundant  set  of  general-purpose  computers  (GPC)  to  control  an  innova- 
tive, multiple-element,  reusable,  manned  spacecraft  through  an  ensemble  of  flight  regimes  never 
before  encountered  by  a single  vehicle.  For  STS-1,  the  PFS  consisted  of  more  than  400  000  computer 
words  of  flight  code,  a complete  test  of  every  possible  combination  of  branch  instruction  or  decision 
point  of  which  would  take  more  than  10  000  years  of  computer  time  on  today's  fastest  computers. 

To  protect  against  a latent  programing  error  (software  fault)  existing  in  an  untried  branch  com- 
bination that  would  render  the  Space  Shuttle  out  of  control  in  a critical  flight  phase,  the  BFS  was 
chartered  to  provide  a safety  alternative.  The  BFS  is  designed  to  operate  in  critical  flight  phases 
(ascent  and  descent)  by  monitoring  the  activities  of  the  Space  Shuttle  flight  subsystems  that  are 
under  control  of  the  PFS  (e.g.,  navigation,  crew  interface,  propulsion),  then,  upon  manual  command  by 
the  flightcrew,  to  assume  control  of  the  Space  Shuttle  and  deliver  it  to  a noncritical  flight  condi- 
tion (safe  orbit  or  touchdown).  Many  technical,  managerial,  and  operational  challenges  were  experi- 
enced by  the  development  team  of  NASA  and  its  contractors  in  bringing  the  BFS  from  a concept  to  a 
working  operational  system.  The  challenges  addressed  herein  are  those  associated  with  the  selection 
of  the  PFS/BFS  system  architecture,  the  internal  BFS  architecture,  the  fault-tolerant  software  mech- 
anisms, and  the  long-term  BFS  utility. 


CHALLENGE  1:  A MANAGEABLE  SYSTEM  ARCHITECTURE 


Central  to  any  concept  of  a reusable  spacecraft  is  the  theme  of  higher  system  reliability 
through  redundancy  of  finite-lived  components.  In  the  Space  Shuttle  avionics,  the  availability  of  a 
properly  functioning  flight  computer  is  assured  through  the  wiring  of  five  identical  GPC's  in  paral- 
lel. Since  the  memory  available  for  state-of-the-art  GPC's  at  the  beginning  of  the  Space  Shuttle  de- 
velopment cycle  was  much  less  than  the  flight  software  requirements  dictated,  an  early  partitioning 
scheme  was  established.  For  each  of  three  flight  phases  (ascent,  on-orbit,  descent),  a redundant 
copy  of  all  critical  functions  was  loaded  in  each  of  four  GPC's  and  the  fifth  GPC  was  loaded  with  a 
complement  of  useful  functions  the  loss  of  which  could  be  tolerated.  This  strategy  assured  protec- 
tion from  multiple,  sequential  computer  hardware  failures,  but  did  not  address  the  possibility  of  a 
software  fault  generic  to  the  set  of  four  redundantly  programed  GPC's  causing  loss  of  control  of  the 
Space  Shuttle.  Concern  for  such  a software  fault  is  valid  in  that  regardless  of  the  number  of  checks 
and  balances  that  are  put  in  place  to  find  and  eliminate  specification  and  coding  errors  in  major 
software  developments,  there  can  be  no  100-percent  assurance  that  latent,  potentially  dangerous  soft- 
ware errors  do  not  exist  in  the  delivered  product. 

The  obvious  strategy  for  increasing  the  software  reliability  of  the  Space  Shuttle  was  through 
software  redundancy,  but  the  challenge  of  the  problem  was  the  form  of  the  redundancy  to  implement 
within  time  and  cost  constraints.  Three  redundancy  alternatives  were  available:  (1)  increasing  the 

internal  PFS  redundancy;  (2)  duplicating  the  PFS  in  another  software  version  programed  by  a different 
set  of  programers  completely  isolated  from  the  PFS  programer,  or  (3)  implementing  a reduced-capability 
backup  system  by  a semi-isol ated  set  of  programers.  The  first  alternative  was  not  pursued  because  it 
was  felt  that  every  practical  internal  measure  was  already  being  pursued  by  the  PFS  designers.  The 
second  alternative  was  considered  too  costly  and  fraught  with  duplication  of  functions  not  essential 
for  a secondary  system.  The  third  alternative  was  selected  since  it  afforded  an  additional  measure 
of  protection  that  was  achievable  within  cost  and  schedule  constraints.  The  reduced  capability  was 
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set  by  a single  memory  load  for  both  ascent  and  descent  in  a single  GPC.  The  BFS  also  assumed  the 
non-flight-critical  functions  that  had  been  scheduled  for  the  nonredundant  fifth  GPC  for  ascent  and 
descent.  The  semi -isolation  of  the  programers  was  achieved  by  having  the  BFS  programed  by  a contrac- 
tor geographically  separated  from  the  PFS  contractor. 


THE  BFS  FAULT-TOLERANT  ARCHITECTURE 


Significant  challenges  were  faced  by  the  designers  to  develop  a BFS  which  would  closely  track 

the  PFS,  protect  itself  and  the  PFS  from  data  pollution  from  each  other,  and  also  be  ready  at  any 

point  in  the  ascent,  abort,  or  descent  profile  to  take  over  control  of  the  vehicle  safely  when  manu- 
ally engaged  by  the  crew.  To  provide  this  capability,  a technique  had  to  be  developed  that  would  pro- 
vide for  tight  synchronization  of  the  BFS  to  the  PFS  in  order  to  prevent  divergence,  but  that  would 

also  protect  both  from  inducing  faults  in  the  other.  A more  pollution-protective  technique  than  that 

used  for  PFS  redundant-set  synchronization  had  to  be  developed.  To  protect  the  PFS  from  faulty  BFS 
data  or  timing,  this  technique  would  permit  no  transfer  of  data  from  the  BFS  to  the  PFS. 

An  innovative  technique  for  synchronization  of  the  BFS  and  the  PFS  was  developed  using  flight- 
critical  data  bus  input  profile  tracking  of  the  PFS  that  involves  use  of  the  input/output  processor 
(IOP)  input  data  bus  listen  capability  and  the  transfer  of  input  profile  and  minor  cycle  data  from 
the  PFS  to  the  BFS.  The  BFS  protects  itself  from  pollution  by  erroneous  input  profile  data  by  voting 
on  the  redundant  data  sent  to  it  by  the  individual  PFS  GPC's.  In  addition,  the  BFS  protects  itself 

from  input  profile  timing  faults  of  the  PFS  by  the  use  of  its  own  data  bus  timing  window  thresholds 

for  each  of  the  individual  groups  of  input  profile  data. 

To  protect  the  BFS  and  PFS  from  pollution  by  erroneous  data  received  from  one  another,  an  in- 
terface design  policy  was  established  which  allowed  no  transfer  of  software-generated  data  from  the 
BFS  to  the  PFS  but  did  allow  data  absolutely  essential  to  the  proper  tracking  of  the  PFS  to  be  trans- 
ferred and  used  by  the  BFS.  The  absence  of  data  transfer  to  the  PFS  prevents  any  pollution  of  the 
redundant  PFS  by  the  BFS.  The  BFS  was  designed  to  protect  itself  from  pollution  from  erroneous  PFS 
data  first,  by  being  limited  to  the  use  of  a small  amount  of  absolutely  essential  transfer  data;  sec- 
ond, by  performing  a vote  on  the  redundant  sets  of  data  obtained  from  the  redundant  PFS  GPC's;  and 

third,  by  performing  reasonableness  checks  on  the  voted  data. 

Another  challenge  faced  in  the  development  of  the  fault-tolerant  BFS  was  the  design  of  a safe 
method  of  taking  control  of  the  vehicle  at  any  point  in  the  flight  profile  without  inducing  control 
effector  transients  which  might  endanger  the  crew  and  the  vehicle.  The  design  developed  to  provide 
this  protection  required  the  input  of  engage  initialization  data  from  the  subsystems  via  the  flight- 
critical  data  buses  immediately  after  BFS  engagement.  These  data  were  then  used  to  ensure  that  subse- 
quent BFS  control  commands  did  not  overstress  or  generate  significant  transients  on  the  control  effec- 
tor subsystem. 

One  of  the  foremost  innovative  techniques  used  in  the  BFS  fault-tolerant  design  was  developed  to 
provide  for  recovery  from  the  loss  of  PFS-generated  master  events  controller  (MEC)  sequencing  as  well 
as  for  attempting  recovery  from  BFS  GPC  hardware  or  software  errors.  The  loss  of  MEC  sequencing  com- 
mands might  occur  either  as  a result  of  a generic  PFS  software  failure  or  as  a result  of  the  abrupt 
termination  of  all  PFS-controlled  flight-critical  data  buses  at  BFS  engagement.  Recovery  from  these 
types  of  errors  is  provided  by  the  BFS  software  restart  technique.  A software  restart  is  initiated 
upon  BFS  engagement,  and,  in  the  event  that  critical  MEC  command  sequences  are  found  not  to  have  been 
properly  performed,  the  BFS  reinitiates  the  full  MEC  sequence  of  commands  for  the  appropriate  mission 
event. 

The  use  of  the  restart  technique  to  attempt  recovery  from  BFS  GPC  hardware  or  software  errors 
was  developed  to  protect  the  BFS  from  transient  errors  and,  in  the  case  of  hard  errors,  to  continue 
attempts  at  recovery  in  hopes  that  the  error  will  not  persist.  This  restart  recovery  involves  re- 
initialization of  input/output  (I/O)  and  restarting  of  BFS  application  processing  at  the  beginning  of 
a new  GPC  major  processing  cycle.  The  restart  recovery  technique  provides  this  protection  for  both 
the  preengaged  and  engaged  modes  of  BFS  operation. 


A MOVING  TARGET:  MAINTAINING  TRACK  OF  SOFTWARE  CHANGES 


Unlike  the  Approach  and  Landing  Test  (ALT)  PFS,  the  BFS  for  ALT  could  not  be  used  as  a base  upon 
which  to  build  Orbital  Flight  Test  (OFT)  software.  The  BFS  software  for  ALT  was  designed  and  de- 
veloped by  Charles  Stark  Draper  Laboratories  and  provided  backup  for  flight  control  functions  only, 
provided  no  CRT/crew  interface,  and  provided  only  a very  minimal  task-list-type  executive.  Rockwell 
was  selected  to  develop  the  BFS  for  OFT  and  essentially  started  anew  about  2 years  behind  the  PFS 
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software  development.  A new  operating  system  had  to  be  designed  and  developed,  all  existing  PFS  re- 
quirements and  change  requests  (CR's)  had  to  be  reviewed  for  applicability  to  the  BFS,  and  an  overall 
BFS  software  design  had  to  be  developed.  The  BFS  not  only  had  to  catch  up  with  the  PFS  level  of  matu- 
rity very  quickly,  but  then  had  to  maintain  pace  with  a very  large  amount  of  PFS  requirements  develop- 
ment and  software  change  activity.  A significant  amount  of  effort  and  manpower  was  required  to  accom- 
plish this  goal. 


POST-OFT  UTILITY  OF  THE  BACKUP  FLIGHT  SYSTEM 


The  BFS  was  initially  envisioned  to  be  used  only  through  the  Shuttle  OFT  flights.  The  expecta- 
tion was  that  after  OFT,  the  entire  Shuttle  system  design,  including  PFS  software,  would  be  proven 
safe  for  operational  use  and,  therefore,  the  BFS  would  no  longer  be  needed.  Close  to  the  end  of  OFT, 
an  examination  was  undertaken  to  assess  the  need  for  continuing  the  use  of  the  BFS.  Assessments  of 
the  PFS  software  discrepancy  report  (DR)  traffic  showed  it  to  correlate  proportionally  to  the  level 
of  PFS  software  change  traffic  but,  even  in  cases  in  which  software  change  traffic  was  small,  the  num- 
ber of  DR's  appeared  to  decay  exponentially  rather  than  to  drop  abruptly.  These  data  indicated  that 
latent  software  errors  had  high  levels  of  persistence.  This  information  was  used  in  conjunction  with 
the  projections  of  PFS  software  change  traffic  for  future  flights.  It  was  determined  that  for  a sig- 
nificant time  in  the  future,  the  PFS  software  change  traffic  would  continue  to  remain  at  significant 
levels  and  therefore  the  risks  would  remain  high  for  latent  PFS  software  errors.  Therefore,  it  was 
concluded  that  for  at  least  a significant  time  in  the  future,  the  BFS  would  be  needed  to  protect 
against  generic  PFS  software  faults. 
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ABSTRACT 


The  Space  Shuttle  Main  Engine  (SSME)  presented  new  requirements  in  the  design  of  controls  for 
large  pump-fed  liquid  rocket  engine  systems.  These  requirements  were  the  need  for  built-in  full 
mission  support  capability,  and  complexity  and  flexibility  of  function  not  previously  needed  in  this 
type  of  application. 

An  engine  mounted  programmable  digital  control  system  was  developed  to  meet  these  requirements. 
The  engine  system  and  controller  and  their  function  are  described.  Design  challenges  encountered 
during  the  course  of  development  included  accommodation  for  a very  severe  engine  environment,  the 
implementation  of  redundancy  and  redundancy  management  to  provide  fail -operational /fail -safe  capabili- 
ty, removal  of  heat  from  the  package,  and  significant  constraints  on  computer  memory  size  and  process- 
ing time. 

The  flexibility  offered  by  programmable  control  reshaped  the  approach  to  engine  design  and  devel- 
opment and  set  the  pattern  for  future  controls  development  in  these  types  of  applications. 


INTRODUCTION 


Development  of  controls  for  the  Space  Shuttle  Main  Engine  (SSME)  presented  many  new  engineering 
challenges  which  had  not  been  previously  faced  in  the  design  of  controls  for  large  pump-fed  liquid 
rocket  engine  systems.  Notable  among  these  challenges  were: 

1.  A requirement  for  built-in  full  mission  support  capability  from  the  early  checkout  phases 
through  main  engine  cutoff  and  propellant  dump  during  flight. 

2.  A need  for  flexibility  and  complexity  of  function  not  previously  attained  in  any  liquid  rocket 
engine  system. 

Most  of  these  challenges  were  the  direct  result  of  a new  orientation  in  control  system  require- 
ments for  rocket  engines  brought  about  by  the  unique  requirement  of  the  Space  Shuttle  for  a reusable 
and  maintainable  man-rated  system. 

The  following  sections, review  requirements  and  give  a general  description  of  the  control  system. 
Some  of  the  major  alternatives  considered  are  discussed  along  with  reasons  for  selecting  the  final 
configuration.  Development  problems  are  reviewed  and  development  experience  evaluated. 


DISCUSSION 


CONTROL  SYSTEM  REQUIREMENTS 

The  SSME  control  system  must  support  engine  utilization  during  all  phases  of  the  mission  sequence 
from  checkout  through  propellant  loading,  liftoff,  flight  and  shutdown  in  orbit.  It  is  required  to 
have  the  capability  of  self-contained  checkout  in  the  assembly  area,  and  at  the  launch  area  prior  to 
flight.  The  control  system  must  also  support  engine  start  preparations,  provide  repeatable  start, 
mainstage  control , and  shutdown  upon  vehicle  command.  In  addition,  it  must  have  the  ability  to  monitor 
engine  critical  operating  parameters  (redlines),  provide  fault  detection,  manage  redundancy  and  report 
engine  status  conditions  during  all  phases  of  operation. 
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The  control  system  is  required  to  vary  engine  thrust  upon  vehicle  command  between  65  and  1 09%  of 
Rated  Power  Level  in  1%  increments  while  maintaining  mixture  ratio  within  specification.  Rated  Power 
Level  (RPL)  is  100%,  while  Full  Power  Level  (FPL)  at  109%  can  be  commanded  when  vehicle  conditions 
require  it. 

Required  thrust  precision  is  +-6000  lb  (3  sigma)  during  steady-state  operation.  Thrust  must  be 
within  steady-state  limits  within  1 second  after  a commanded  change  without  rate  of  change  exceeding 
7000  lb/10  ms.  Mixture  ratio  accuracy  is  required  to  be  within  +-1%.  The  engine  must  be  capable  of 
accelerating  from  start  signal  to  RPL  in  3.9  seconds  with  mixture  ratio  within  tolerance  in  less 
than  5.5  seconds. 

Requirements  include  on-board  checkout  capability,  redundancy  verification,  and  status  monitoring 
for  systems  verification  during  ground  and  flight  operations.  Rapid  fault  isolation  techniques  are 
required  which  activate  or  deactivate  redundant  components  without  unduly  disturbing  engine  operation. 
The  control  system  is  also  required  to  provide  automatic  checkout  of  engine  functional  components  with 
fault  isolation  to  Line  Replaceable  Units  (LRU)  during  ground  checkout  to  minimize  vehicle  turnaround 
time,  and  to  be  capable  of  subsystem  replacement  without  engine  recalibration. 

All  critical  electrical  elements  of  the  control  system  must  be  redundant  for  a fail -operational/ 
fail-safe  design. 


ENGINE  AND  CONTROL  SYSTEM  DESCRIPTION 

The  SSME  is  a reusable,  high  performance,  Liquid  Hydrogen/Oxygen , rocket  engine  designed  and 
produced  by  the  Rocketdyne  Division  of  Rockwell  International  under  contract  with  Marshall  Space 
Flight  Center.  It  has  four  turbopumps  (two  low-pressure  and  two  high-pressure) , two  preburners, 
a main  combustion  chamber,  five  hydraul i cal ly  actuated  propellant  control  valves,  sensors,  and  an 
engine  mounted  electronic  digital  controller.  The  staged-combustion  cycle  burns  low  mixture  ratio 
propellants  in  the  preburners  first.  These  fuel-rich  gases  are  used  to  drive  the  high-pressure 
turbopumps  and  are  then  routed  to  the  main  combustion  chamber  where  they  are  burned  with  additional 
oxidizer  to  obtain  maximum  performance. 

Performance  control  is  closed-loop  feedback  control  with  full  authority  over  the  engine  operating 
range.  The  control  block  diagram  is  illustrated  in  Fig.  1.  Thrust  and  mixture  ratio  control  are 
provided  by  adjusting  the  power  to  the  two  high-pressure  turbopump  turbines  through  control  of  the 
oxidizer  flow  to  the  preburners  with  modulating  preburner  oxidizer  valves.  Thrust  control  is 
provided  by  modulation  of  the  oxidizer  preburner  oxidizer  valve,  and  mixture  ratio  control  is 
accomplished  by  modulation  of  the  fuel  preburner  valve.  Cross-feed  compensation  from  the  oxidizer 
preburner  valve  command  to  the  fuel  preburner  valve  is  used  to  minimize  the  effects  of  thrust 
transient  changes  on  engine  mixture  ratio.  In  addition  to  the  two  preburner  valves  used  in  perfor- 
mance control,  three  other  propellant  valves  are  scheduled  to  initiate  propellant  flow  during  start 
and  to  assist  in  control  of  shutdown.  In  addition  the  chamber  coolant  valve  is  scheduled  as  a 
function  of  thrust  to  prevent  overheating  in  the  nozzle  and  combustion  cooling  circuit  as  the  engine 
is  throttled.  More  detailed  descriptions  of  the  control  logic  and  hardware  are  contained  in 
Ref.  1 and  2. 

The  controller,  which  was  designed  and  manufactured  by  Honeywell,  Incorporated,  is  mounted  on  the 
side  of  the  main  combustion  chamber.  It  is  a single,  integral  electronics  package  containing  dual 
programmable  digital  computers,  each  with  16384  words  of  memory.  The  Honeywell  HDC-601  digital 
computer  with  2 mil  plated  wire  memory  is  used  in  the  controller.  Input  electronics,  computers,  power 
supplies,  and  output  electronics  are  dual  redundant.  Fig.  2,  with  cross-strapping  at  the  input  and 
output  of  the  computer  electronics.  Installation  characteristics  are  listed  in  table  1.  The 
controller  interfaces  (Fig.  3)  with  67  sensor  inputs  and  43  output  device  channels.  Controller  to 
vehicle  interfaces  include  3 redundant  vehicle  command  channels,  2 status  recorder  output  channels, 

2 redundant  power  channels,  and  a 28  vdc  input  for  heater  operation  in  orbit.  The  status  recorder 
channels  transmit  128  data  words  every  40  milliseconds  to  the  vehicle  data  bus. 
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DESIGN  ALTERNATIVES  AND  DEVELOPMENT  CONSIDERATIONS 


Controller  Location  and  Mounting 

Both  mechanical  and  electrical  problems  were  experienced  during  the  design  and  development. 

Early  studies  clearly  showed  the  controller  should  be  engine  mounted  to  provide  an  integral  complete 
engine  system  and  to  avoid  routing  in  excess  of  four  hundred  wires  across  the  gimballed  engine 
interface.  Presently  there  are  a total  of  twenty  three  wires  across  the  interface  for  power, 
commands,  memory  loading,  status  data,  controller  heater  power,  and  analog  temperature  measurement. 

The  controller  was  initially  designed  to  be  hard  mounted  vertically  against  the  thrust  chamber 
with  a reguirement  to  meet  a 22.5  grms  vibration  environment.  This  was  a very  severe  constraint  on 
controller  mechanical  design  so  the  controller  mounting  was  subseguently  changed  to  use  rubber  inserts 
which  reduced  the  vibration  environment  to  approximately  4 grms. 


Digital  Versus  Analog  and  Hardware  Software  Partitioning 

Although  the  selection  of  digital  versus  analog  implementation  of  control  logic  would  be  heavily 
weighted  in  favor  of  programmable  digital  today,  the  case  was  not  so  clear-cut  in  1970  when  decisions 
of  this  nature  were  being  made.  However,  the  complexity  of  functions  and  need  for  ease  of  change  in 
logic  during  the  early  phases  of  engine  development  weighted  the  decision  towards  digital  programmable 
controls.  The  valve  positioning  curves  of  Fig.  4 are  an  illustration  of  the  case  in  point.  All  five 
engine  propellant  valves  are  commanded  to  multiple  positions  during  the  start  seguence.  Up  to  seven 
different  positions  and  rates  are  commanded  to  each  propellant  valve  during  the  3.9  second  engine 
start  seguence.  The  parameters  for  these  valve  positioning  commands  were  changed  many  times  during 
the  engine  development  program  in  order  to  obtain  the  desired  start  characteristics. 

Complexity  and  immaturity  of  the  control  algorithms  and  checkout  functions  also  reguired  the 
flexibility  of  a programmable  system.  In  addition,  calibration  factors  unigue  to  each  engine  were 
reguired  to  be  stored  and  utilized  by  the  controller. 


Packaging  and  Heat  Removal 

The  controller  electronics  are  mounted  on  conventional  printed  circuit  cards.  The  printed 
circuit  cards  are  retained  in  the  controller  chassis  by  a rigid  foam  packaging  system  which  further 
isolates  the  electronics  from  the  vibro-acoustic  environment  of  the  engine.  In  this  packaging 
system,  the  chassis  is  divided  into  cavities,  each  of  which  accepts  two  cards.  Each  card  has  an  open 
foam  grid  attached  to  the  component  mounting  side  and  a foam  half-wedge  attached  to  the  back  side. 

The  cards  are  retained  in  the  chassis  cavity  by  loading  a foam  wedge  between  the  two  cards.  This 
provides  for  very  tight  card  retention  as  well  as  isolation  from  vibration  transmitted  through  the 
chassis  and  it  detunes  the  printed  circuit  card/chassis  structure  system.  This  protected  the  modules 
from  vibration  but  created  a problem  i r.  dissipating  the  heat  from  the  cards.  A design  change 
was  made  so  that  the  foam  grids,  which  are  in  contact  with  both  the  printed  circuit  cards  and  chassis 
walls,  have  an  aluminum  foil  surface  which  provides  heat  transfer  from  the  electronic  parts. 

Cooling  is  accomplished  by  conductive  heat  transfer  through  the  chassis  and  convection  heat  transfer 
from  the  chassis  surface  to  the  atmosphere.  Additional  chassis  surface  area  is  obtained  by  extensive 
use  of  pin  fins  machined  into  the  chassis. 


Electrical  and  Memory  Problems 


Other  notable  problems  were  the  memory  system  and  power  supply.  Plated  wire  was  selected  for  the 
memory  based  on  speed,  power,  non-volatility,  and  non-destructive  readout.  At  the  time  of  design, 
five  mil  diameter  wire  was  being  used  on  several  programs.  However,  two  mil  wire  was  selected  for 
the  controller  to  reduce  size  and  power.  Many  problems  were  encountered  in  the  development  of  the 
memory  system  until  a "coupled  film"  plating  was  developed  and  used  on  both  the  SSME  and  Viking 
programs. 
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Input  power  to  the  controller  was  selected  to  be  115  volt,  400  Hz  three-phase  in  preference  to 
28  vdc.  A small  transformer  on  the  input  provides  power  for  operating  the  power  supply.  The  primary 
load  is  three-phase  full -wave  rectified  resulting  in  270  vdc  to  be  switched  by  the  switching  regulator. 
Potential  faults  on  the  input  bus  from  other  users  resulted  in  a requirement  to  be  able  to  operate 
down  to  95  volts  rms  for  up  to  one  second.  A boost  stage  regulator  was  employed  to  accommodate  this 
requirement.  A problem  of  high  current  demand  of  engine  solenoid  loads  during  power  recovery  and 
engine  start  operation  was  solved  by  dividing  the  solenoids  into  banks.  The  biggest  problem  of  all 
in  the  power  supply  was  packaging  the  unit  in  the  space  available. 


Software  Design 

Software  program  organization  as  it  finally  evolved  is  illustrated  in  Fig.  5.  Because  of  computer 
memory  size  constraints  three  types  of  program  configurations  are  resident  in  memory  at  different 
times  depending  upon  the  phase  of  mission  operations.  Changes  in  configuration  are  accomplished  by 
use  of  "roll-in"  modules  of  code  which  overlay  pre-existing  code  and  change  controller  function.  All 
coding  is  in  DAP-16  assembly  language. 

The  ground  checkout  configuration  is  used  during  component  checkouts.  This  configuration  has  five 
sub-configurations,  each  designed  to  facilitate  automated  checkout  of  different  elements  of  the 
engine  and  controller  such  as  actuators,  pneumatic  solenoid  valves,  sensors,  ignitors  and  redundancy. 

The  flight  readiness  test  (FRT)  configuration  is  used  to  perform  an  extensive  system  test  of  the 
engine  and  controller  without  initiating  powered  operation  of  the  engine.  This  test  configuration 
includes  a simplified  digital  dynamic  model  of  the  engine  which  produces  simulated  pressures,  tempera- 
tures and  flows  in  response  to  measured  engine  valve  positions.  These  simulated  parameter  values  are 
substituted  for  actual  sensor  readings  and  used  by  the  controller  to  "run"  the  engine  with  the  same 
logic  as  used  in  powered  operation  during  flight. 

The  flight  configuration  is  used  for  engine  start  preparation,  start,  and  all  flight  operational 
phases. 

Dominant  constraints  on  software  design  were  process  time  and  memory  size.  Dynamic  simulation 
studies  of  the  engine  system  early  in  the  program  demonstrated  that  a major  cycle  (control  iteration) 
time  of  .02  seconds  or  less  was  necessary  in  order  to  provide  adequate  control  response  capability  in 
the  event  of  certain  types  of  oxidizer  preburner  oxidizer  valve  actuator  failures.  Worst  case  major 
computation  cycle  time  grew  rapidly  in  the  early  years  of  the  program,  reaching  .018  seconds  in  the 
first  few  years.  An  on-going  effort  was  necessary  to  hold  the  line  on  this  parameter. 

Program  size  grew  much  faster  and  larger  than  ever  seemed  reasonable  to  anticipate  given  the 
requirements  as  they  were  understood  at  the  beginning  of  the  project.  At  the  very  beginning  it 
was  estimated  that  8000  words  would  be  sufficient  for  all  program  requirements,  so  12000  words 
memory  capacity  was  proposed.  Requirements  to  vote  variable  commands  from  the  orbiter  with  software 
rather  than  hardware,  requirements  to  do  an  FRT,  and  other  changes  necessitated  expanding  the  memory 
to  16000  words.  Fig.  6 documents  memory  requirement  estimates  over  the  11  year  life  of  the  program. 

Early  phases  of  program  size  growth  were,  to  a great  extent,  the  result  of  maturing  of  system 
requirements  as  detailed  engine  hardware  design  and  development  progressed.  Program  size  initially 
grew  rapidly  as  the  complexity  of  checkout  requirements  increased.  This  early  rapid  growth  resulted 
in  a decision  in  mid-1973  to  separate  checkout  functions  from  the  flight  portion  of  the  program  and 
to  implement  the  roll-in  module  concept.  The  roll-in  concept  was  further  implemented  late  in  1974 
with  the  conversion  of  the  sample  problem  element  of  the  software  to  a roll-in  module. 

Since  1976  there  has  been  a continuous  effort  to  work  within  the  memory  size  constraint.  Design 
scrubs  are  necessary  in  order  to  allow  implementation  of  new  requirements.  In  the  course  of  develop- 
ment 12  major  software  program  versions  have  been  issued  with  many  more  interim  revisions.  Maximum 
resident  code  today  is  15696  16  bit  plus  parity  words.  Total  program  code  including  roll-in  modules 
is  23349  words.  Over  200,000  words  of  code  have  been  implemented  or  rearranged  in  the  course  of  the 
software  effort. 

A more  detailed  discussion  of  avionics  software  development  is  presented  in  Ref.  3. 


41 


Control  System  Integration 


The  SSME  control  system  is  a complex  hardware/software  system.  Extensive  analysis  and  testing 
was  necessary  to  develop  and  verify  the  control  system  hardware/software  implementation.  Detailed 
digital  and  analog  modeling  studies  were  performed  at  Rocketdyne  to  characterize  engine  control 
characteristics.  These  studies  were  extended  at  Honeywell  in  detailing  the  controller  design. 
Extensive  simulation  testing  of  the  control  system  was  performed  at  Honeywell  using  an  analog  model 
of  the  engine  and  a Command  and  Data  Simulator  to  simulate  the  orbiter  interface.  More  recently  the 
majority  of  the  control  system  testing  has  been  accomplished  at  the  Huntsville  Simulation  Laboratory 
(Ref.  4).  This  laboratory  employs  actual  flight  configuration  control  system  hardware  (controller, 
sensors,  actuators,  etc.)  interfaced  to  a hybrid  analog/digital  real-time  engine  system  simulator. 

The  Simulation  Laboratory  provides  a high  fidelity  test  bed  which  allowed  detailed  integration 
testing  of  the  control  system  prior  to  use  in  actual  SSME  test  firings.  Since  the  initiation  of 
engine  test  firings,  the  Simulation  Laboratory  has  continued  to  be  extensively  used  for  software 
verification  and  engine  test  support  and  more  recently  for  flight  support. 


EVALUATION  OF  DEVELOPMENT  EXPERIENCE 

The  SSME  Digital  Control  System  has  been  utilized  for  all  engine  test  firings.  As  of  this 
writing,  40  different  SSME's  have  accumulated  a total  of  tfver  1000  test  firings,  including  6 orbital 
flights,  and  over  50  hours  of  powered  operation. 

As  the  SSME  system  has  matured  through  this  program,  many  control  system  requirement  additions 
and  changes  have  been  made.  The  flexibility  provided  by  use  of  a fully  programmable  digital  computer 

has  allowed  the  majority  of  these  changes  to  be  accomplished  by  software  modification.  This  has 

facilitated  rapid  change  incorporation  and  verification  (through  use  of  the  Simulation  Laboratory) 
with  only  minor  perturbation  to  engine  test  schedules. 

Development  of  the  SSME  would  not  have  been  possible  in  a practical  sense  without  the  use  of 
programmable  digital  control.  Even  though  the  introduction  of  operational  software  added  a signifi- 
cant new  cost  element  to  rocket  engine  development,  and  cost  saving  benefits  far  outweighed  the 
software  costs.  The  very  flexibility  offered  by  programmable  control,  from  the  beginning  of  the 
program  reshaped  the  approach  to  engine  design  and  development.  It  is  unlikely  any  pump- fed  throttle 
able  and  reusable  liquid  rocket  engine  of  the  future  will  be  designed  without  this  approach. 

The  importance  of  good  simulation  of  the  engine  system,  fault  insertion  capability,  the  use  of 

prototype  hardware  which  can  be  easily  modified,  and  the  capability  for  memory  history  tracking 
cannot  be  over  emphasized.  These  capabilities  will  be  essential  to  cost  effective  and  timely  develop 
ment  of  any  future  system  of  this  nature. 

There  is  never  enough  memory  or,  conversely,  the  program  always  expands  to  fill  the  space  avail- 
able. This  situation  is  not  necessarily  bad.  As  the  hardware  aspects  of  a program  mature  the 
number  of  practical  options  to  fix  problems  diminish.  Software,  as  it  matures,  still  retains  the 
ability  to  absorb  small  changes  on  a short  turn-around  time  basis.  This  factor  should  be  given  more 
weight  at  the  beginning  of  a program.  In  the  case  of  the  SSME  the  nearly  300  percent  increase  in 
program  size  from  original  estimates  was  largely  the  result  of  immaturity  of  system  requirements 
at  the  program  onset.  Unless  the  software  requirements  are  well  defined  and  mature  from  prototype 
system  testing,  program  size  estimate  increases  of  100  to  200  percent  should  not  be  surprising. 

The  existing  controller  program  is,  of  necessity,  in  assembly  language  because  of  processing 
speed  and  memory  size  limitations.  Recent  developments  in  microprocessors  and  memories  have  made 
practical  significantly  faster  processing  speeds  and  greater  memory  capacity  at  no  expense  in  size 
or  power  relative  to  the  existing  controller.  If  software  requirements  can  be  maintained  within 
bounds  these  increased  capacities  may  enable  the  use  of  higher  order  languages  in  future  engine 
controllers,  thus  reducing  the  cost  of  producing  software  and  increasing  its  reliability. 
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CONCLUSIONS 


The  requirements  for  the  Space  Shuttle  Main  Engine  dictated  a control  system  design  that  was 
unique  to  large  pump-fed  rocket  engines.  The  digital  programmable  ful 1 -authority  control  implemented 
has  demonstrated  its  ability  to  meet  or  exceed  all  mission  requirements.  The  very  flexibility  offered 
by  programmable  control  reshaped  the  approach  to  engine  design  and  development.  The  success  and 
benefits  of  this  approach,  demonstrated  with  the  Shuttle  Main  Engines,  have  set  the  pattern  for  the 
future  in  development  of  controls  for  this  type  of  application. 
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TABLE  1 CONTROLLER  INSTALLATION  CHARACTERISTICS 


SIZE 


23.5  X 14.5  X 17.0  INCHES 


WEIGHT 


211  POUNDS 


INPUT  POWER 


490  WATTS  (STANDBY) 
600  WATTS  (MAINSTAGE) 


HEAT  TRANSFER 


FORCED  AIR  COOLING  (GROUND) 
CONVECTIVE  COOLING  (FLIGHT) 


MOUNTING 


FOUR  POINT  VIBRATION  ISOLATORS 


VIBRATION 

ENVIRONMENT 


SINE 

RANDOM 


24  G’s  PEAK 
22.5  G’s  RMS 


TEMPERATURE 

ENVIRONMENT 


OPERATIONAL  -50  TO  +95F 

NON-OPERATION AL  -200  TO  +200F 
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FIGURE  1 PERFORMANCE  CONTROL  DIAGRAM 


FIGURE  2 SIMPLIFIED  REDUNDANCY  DIAGRAM 
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FIGURE  3 CONTROLLER  INTERFACES 


START 

CONTROL 

PHASE 


OPEN  LOOP 

CLOSED-LOOP  THRUST  CONTROL 
CLOSED-LOOP  M/R  CONTROL 


0 0.5  1.0  1.5  2.0  2.5  3.0  3.5  • 4.0  4.5  5.0  5.5  60 


TIME  FROM  START  SIGNAL  (SECONDS) 

FIGURE  A TYPICAL  ENGINE  START  SEQUENCE  TO  RPL 
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PROGRAM  SIZE  - THOUSAND  OP  WORDS 


ORIGINAL  PAGE  IS 
OF  POOR  QUALITY 


GROUNO 

CHECKOUT 


FLIGHT  READINESS  FLIGHT 

TEST  CONFIGURATION  CONFIGURATION 


‘in  DU  ruis  unity  worms 


FIGURE  5 SOFTWARE  PROGRAM  COMPONENTS  AND  CONFIGURATIONS 


YEAR 


FIGURE  6 CONTROLLER  MEMORY  REQUIREMENT  ESTIMATES 
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MAN-MACHINE  INTERFACE  AND  CONTROL  OF  THE 
SHUTTLE  DIGITAL  FLIGHT  SYSTEM 


Richard  D.  Burghduff  and  James  L.  Lewis,  Jr. 
NASA  Lyndon  B.  Johnson  Space  Center 
Houston,  Texas  77058 


The  challenge  in  designing  the  Orbiter  displays  and  controls  (D&C)  system  was  to  integrate  the 
required  aircraft  and  spacecraft  D&C  in  the  space  available  within  the  pilot's  reach  and  vision. 

Some  of  the  basic  requirements  for  the  D&C  system  were  as  follows: 

1.  A safe  return  with  a single  crewman  from  either  forward  crew  station 

2.  Normal  operation  (exclusive  of  payload  management)  of  all  mission  phases  using  a flightcrew 
of  two 

3.  Accessibility  to  the  flightcrew  from  the  flight  seats  of  D&C  required  for  vehicle  or 
subsystem  management  during  ascent  and  entry 

4.  D&C  to  provide  for  crew  override  of  automated  critical  command  functions 

5.  Crew  selection  of  automatic  or  manual  flight  guidance  and  control 

6.  The  means  to  annunciate  and  command  safing  of  hazardous  systems 

7.  Interior  and  exterior  illumination  consistent  in  type  and  quality  for  crew  operations 

In  early  1970,  the  D&C  system  was  evolving  into  an  integrated,  multipurpose  data  bus  connected 
system  (fig.  1).  Front  station  concepts  were  to  use  five  or  six  cathode-ray  tubes  (CRT's)  for  most 
of  the  display  requirements  and  reformattable  control  panels  and  keyboards  for  most  of  the  controls. 
Some  dedicated  switches  were  used  for  system  initialization  and  where  immediate  crew  access  was 
required.  Circuit  breakers  were  used  for  power  control.  A head-up  display  (HUD)  was  used  for  out- 
the-window  display  presentation.  The  HUD  is  an  electronic/optical  device  that  presents  essential 
flight  information  in  the  pilot's  head-up  field  of  view.  The  information  is  projected  from  a small 
CRT  onto  a combiner  glass  and  collimated  at  "infinity"  to  overlay  the  out-the-window,  "real  world" 
scene. 

During  the  phase  B contract  studies,  conventional  and  integrated  avionics  systems  were  compared 
for  weight,  power,  cost,  and  technology  risk.  With  involvement  of  flight  crewmen  and  flight  opera- 
tion engineers,  many  studies  of  electronic  attitude  direction  indicators  (EADI's)  versus  conventional 
attitude  direction  indicators  (ADI's)  and  multipurpose  data  bus  versus  hardwired  D&C  were  conducted. 
The  Orbiter  program  management  then  chose  a low-risk  off-the-shelf  technology  approach . This  choice 
eliminated  the  EADI's,  the  HUD's,  and  the  multipurpose  displays  and  controls.  Dedicated  D&C  compo- 
nents with  electromechanical  displays  and  hardwired  switches  were  used,  although  four  multifunction 
displays  with  keyboards  were  retained  for  the  digital  system  interface. 

The  Orbiter  contract  was  awarded  to  Rockwell  International  and  the  subsystem  engineers  at  both 
Rockwell  and  the  NASA  Lyndon  B.  Johnson  Space  Center  (JSC)  started  working  together  to  complete  the 
detail  design  of  the  D&C  system.  One  agreement  that  proved  to  be  very  valuable  was  to  initiate  a se- 
ries of  formal  D&C  reviews  at  Rockwell  chaired  by  the  Rockwell  and  JSC  D&C  Work  Breakdown  Structure 
(WBS)  managers.  There  were  13  of  these  major  reviews  during  which  representatives  from  the  flight- 
crew, flight  operations,  engineering,  reliability,  safety,  program  office,  payloads,  software,  NASA 
John  F.  Kennedy  Space  Center,  Rockwell,  and  the  U.S.  Air  Force  were  present.  The  reviews  averaged  46 
people  including  4 astronauts.  The  reviews  were  2 to  3 weeks  long  with  the  first  week  consisting  of 
the  Rockwell  subsystem  engineers  describing  their  subsystem  and  the  D&C  engineers  presenting  the  D&C 
concept  for  the  subsystem.  This  procedure  allowed  NASA  to  ask  questions  of  the  subsystem  engineers 
to  understand  the  system  and  the  Rockwell  concept  of  the  operation.  Many  times,  a subsystem  engineer 
desired  more  D&C  for  his  subsystem  than  was  required  for  operational  use.  This  method  of  review  also 
provided  consistency  between  the  different  subsystems  D&C  requirements.  Rockwell  produced  a compre- 
hensive blue  book  handout  for  these  reviews,  and  review  item  dispositions  (RID's)  could  be  written 
for  consideration  by  the  formal  board  chaired  by  the  JSC  Orbiter  Project  Manager  a week  later. 

By  the  end  of  the  first  week,  the  subsystem  information  for  the  review  was  completed  and  the 
RID's  were  written.  A few  JSC  people  would  stay  for  the  second  week  with  the  flightcrew  and  deter- 
mine subsystem  by  subsystem  the  D&C  required  and  the  appropriate  nomenclature.  Full-size  drawings 
were  used  to  arrange  the  D&C  panel  configuration.  A full-size  foam  core  mockup  was  made  of  the 
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FIGURE  1.-  EARLY  D&C  SYSTEM. 


cabin  area,  and  cutouts  of  the  D&C  were  used  to  determine  the  proper  location  within  the  reach 
and  visibility  requirements  derived  from  other  studies.  The  fllghtcrew's  support  was  Invaluable 
during  these  design  sessions.  At  the  end  of  each  review,  Rockwell  produced  a D&C  configuration 
drawing  and  updated  the  cabin  mockup  to  be  ready  for  the  next  D&C  review,  where  the  process  would 
be  repeated.  As  the  subsystems  became  firm,  the  D&C  panel  layout  and  nomenclature  were  baselined 
and  put  under  configuration  control.  Panel  components  were  selected,  meter  scaling  was  chosen, 
and  caution  and  warning  (C&W)  parameters  were  baselined. 

The  D&C  reviews  were  progressive  as  a function  of  Orbiter  system  maturity,  where,  in  general,  D&C 
reviews  1 through  5 designed  the  0V-101  system,  D&C  reviews  5 through  11  designed  the  0V-102  system, 
and  D&C  reviews  12  and  13  completed  the  0V-099  or  operational  system.  Between  the  formal  reviews,  a 
series  of  change  package  teleconferences  was  held  between  JSC  and  Rockwell  to  get  JSC  engineering  and 

flightcrew  participation  in  parallel  with  the  Rockwell  design  process.  These  teleconferences  are 

continuing  much  less  frequently,  to  discuss  D&C  changes  required  in  response  to  subsystem  design 
changes.  These  teleconferences  greatly  reduced  the  quantity  of  D&C  items  that  would  otherwise  go  to 
the  JSC  Configuration  Control  Board  (CCB).  All  change  package  teleconferences  were  documented  with 
a set  of  minutes. 

Early  in  the  D&C  design  process,  it  was  discovered  that  existing  human  factors  D&C  requirements 
documents  should  be  used  as  design  guides  and  not  firm  design  requirements.  With  JSC  crew  station 

engineers  and  flightcrew  participation  in  the  design  process,  many  of  the  human  factors  requirements 

were  modified  to  produce  a much  better  D&C  system  design.  One  example  of  this  approach  was  the  yel- 
low pointers  now  used  on  the  flight  control  electromechanical  displays,  especially  the  surface  posi- 
tion indicator  (SPI).  Rockwell  made  a mockup  of  an  SPI  (which  contains  nine  scales)  using  the  stand- 
ard white  pointers.  The  crew,  after  determining  the  pointers  were  not  visible  enough,  recommended 
yellow.  Another  good  example  was  the  background  lighting  specification  for  the  pushbutton  switches 
and  the  annunciators.  Using  the  recommended  specification  light  levels,  the  annunciator  lighting  was 
satisfactory  in  the  laboratory.  To  be  certain  the  annunciator  lighting  was  readable  in  sunlight,  sam- 
ple devices  were  installed  in  the  JSC  one-g  trainer  and  it  was  towed  outside.  The  trainer  was  po- 
sitioned so  that  the  sunrise  would  shine  through  the  cockpit  windows.  It  was  discovered  that  the 
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annunciator  status  could  not  be  determined  because  the  resulting  Sun  shafting  washed  out  the  lighted 
annunciation.  The  annunciation  was  changed  from  lighted  background  to  lighted  legend,  and  optical  el- 
ements were  added  to  concentrate  the  light.  This  change  raised  the  intensity  and  contrast  suffi- 
ciently to  provide  annunciator  legibility  in  full  sunlight. 

Early  in  the  D&C  panel  configuration  design,  it  was  decided  to  group  subsystem  controls  by  func- 
tion. However,  associated  circuit  breakers  were  separated  because  of  a concern  that  if  the  higher 
power  circuits  behind  the  circuit  breakers  did  have  an  electrical  fault  or  mechanical  damage  in  a par- 
ticular location,  the  entire  subsystem  could  be  affected.  To  lessen  the  training  impact  on  the  crew, 
the  circuit  breakers  for  each  system  were  positioned  at  the  same  relative  location  on  different 
panels  or  section  of  panels. 

A numbering  system  for  every  panel  surface  was  provided  by  the  crew  station  engineers.  This  sys- 
tem is  necessary  when  referring  to  a control  location,  especially  on  test  and  operational  procedures 
or  schematics.  The  panels  are  numbered  from  left  to  right  or  front  to  aft  in  the  cabin.  Letters  are 
used  for  locations  such  as  R for  right  side,  0 for  overhead,  L for  left  side,  C for  center  console, 

A for  aft,  and  M for  middeck. 

The  foam  core  evaluator  was  a valuable  tool  for  D&C  panel  component  location.  The  D&C  compo- 
nents were  located  by  priority  with  the  systems  that  need  to  be  reached  and  viewed  during  maximum  as- 
cent acceleration  positioned  first.  Other  controls  that  require  operation  during  periods  in  which 
the  crew  is  strapped  in  the  seats  were  positioned  next,  then  lower  order  subsystem  D&C  components 
were  positioned  in  the  aft  flight  deck  and  the  middeck.  A more  advanced  analysis  capability  was  used 
later  in  the  program  to  assess  crew  accessibility  to  various  displays  and  controls.  Specifically,  a 
three-dimensional  graphics  computer-aided  design  modeling  package  was  used  to  depict  a crewman's  ac- 
cess to  various  D&C  components  under  negative-g  conditions  during  a contingency  two-engine-out  abort 
maneuver.  The  access  depicted  by  the  reach  modeling  program  was  then  verified  in  a mockup.  By  in- 
creasing use  of  such  modeling  and  simulation  techniques,  front-end  mockup  costs  are  reduced.  Such 
techniques  will  not  replace  mockups,  but  will  permit  rapid  evaluations  of  many  configuration  alterna- 
tives during  conceptual  and  preliminary  phases  before  the  construction  of  mockups. 

The  aft  flight  deck  was  divided  into  three  zones  designated  mission  station,  on-orbit  station, 
and  payload  station.  The  mission  station  was  assigned  the  D&C  to  manage  flight-critical  payload 
subsystem  controls  and  non-flight-critical  Orbiter  subsystem  controls.  A CRT  and  keyboard  is  at  this 
station  to  display  subsystem  information.  The  on-orbit  station  is  separated  into  the  on-orbit  and 
the  remote  manipulator  system  (RMS)  functions.  The  on-orbit  station  has  an  overhead  window  and  a pay- 
load  bay  window;  D&C  for  the  functions  of  rendezvous,  docking,  TV,  lighting,  and  communications  are 
located  here.  The  RMS  station  contains  D&C  for  manipulator  arm  operations  and  an  overhead  and  aft 
view.  The  RMS  operator  shares  D&C  for  TV,  lighting,  and  communications  with  the  on-orbit  station; 

RMS  operations  require  the  simultaneous  use  of  two  three-degree-of -freedom  hand  controllers.  The  op- 
erator also  must  set  up  views  from  as  many  as  seven  TV  cameras  in  the  payload  bay  on  two  monitors, 
both  of  which  have  a split-screen  capability.  During  some  payload  deployment  and  retrieval  oper- 
ations, a crewman  would  be  well  served  to  have  four  arms  to  accomplish  all  the  required  tasks  in 
the  necessary  timeframe.  As  it  Is,  the  operational  conf Iguration  of  the  RMS  station  contains  only 
about  one-third  of  the  D&C  originally  proposed  and  evaluated  for  that  function.  The  payload  station 
was  reserved  for  payload-provided  D&C  except  for  an  audio  and  station  lighting  panel.  The  middeck 
panel  areas  were  designated  for  circuit  breakers,  housekeeping  functions,  middeck  audio  and  lighting 
controls,  and  airlock  controls. 

Maintainability  of  the  D&C  panels  and  the  line  replaceable  units  (LRU's)  was  a strong  driver  in 
the  D&C  design.  The  D&C  panels  were  designed  to  be  small  enough  to  be  removed  individually.  There  are 
more  than  80  panels  in  the  Orbiter  and  many  include  hinges  to  allow  the  panels  to  be  swung  out  for  ac- 
cess behind  them.  Each  LRU  is  mounted  from  the  front  of  the  panel  and  can  be  installed  and  replaced 
without  removing  the  panel. 

The  Orbiter  operates  in  a zero-g  environment  while  on  orbit;  therefore,  any  contaminants  or  ex- 
traneous materials  are  free  to  migrate.  These  materials  can  be  conductive  and  of  sufficient  length 
to  bridge  terminals  on  such  devices  as  switches,  circuit  breakers,  and  meters.  To  prevent  this  even- 
tuality, all  exposed  electrical  terminations  on  the  panels  are  protected  with  a conformal  coat  of 
resilient  insulating  material,  which  also  provides  a humidity  barrier.  As  with  the  external  termina- 
tions on  the  D&C  equipment  items,  the  internal  terminations  are  also  treated  to  eliminate  the  possi- 
bility of  floating  conductive  particles  causing  failures. 

All  Orbiter  equipment  and  particularly  items  in  the  crew  compartment  are  required  to  meet  very 
stringent  flammability  and  toxicity  requirements.  This  requirement  means  that  all  exposed  materials 
(not  contained  within  at  least  an  environmentally  sealed  enclosure)  must  be  reviewed  by  materials  and 
processing  specialists  for  approval  before  use.  In  numerous  cases  in  which  existing  hardware  was 
used,  special  testing  was  required  to  determine  the  flammability,  toxicity,  and  outgassing  character- 
istics of  specific  materials  for  which  these  data  were  not  available.  When  an  unacceptable  material 
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could  not  be  changed,  it  was  overcoated  or  otherwise  protected,  and,  in  some  cases,  waivers  were 
granted  after  analysis  indicated  acceptability  because  of  configuration,  quantity,  etc. 

One  early  problem  was  a means  of  complying  with  the  NASA  design  standards  that  included  a prohi- 
bition on  the  use  of  frangible  materials.  Most  of  the  existing  display  devices  such  as  CRT's  and 
meters  used  a glass  window  as  a means  of  providing  visual  access  and  sealing  the  instrument  case.  To 
circumvent  this  problem,  most  display  devices  with  glass  were  provided  with  a Lexan  cover  over  the 
window  to  protect  the  glass  and  contain  the  glass  in  the  eventuality  of  a fracture.  These  Lexan 
covers  were  easily  removable  for  maintenance.  The  protective  covers  were  coated  with  antiref lective 
material  for  correct  optical  properties  and  have  proven  very  practical  in  actual  usage.  Other  protec- 
tive devices  were  designed  to  protect  the  D&C  from  a crewman  possibly  causing  damage  to  the  D&C  hard- 
ware while  floating  around  the  cabin.  Wickets  were  placed  around  the  switches  on  most  of  the  panels, 
and  on  the  panels  the  crew  was  most  likely  to  step  on,  the  switches  were  recessed  into  the  panel. 

Lighting,  both  internal  and  external,  would  appear  to  be  a straightforward  area;  however,  much 
design  effort  went  into  the  Orbiter  lighting.  Lighting  in  the  cabin  consists  of  fluorescent  lights 
for  general  area  illumination,  incandescent  floodlights  for  spot  illumination,  and  integral  lighting 
for  meters  and  panel  nomenclature  illumination.  A good  full-size  cabin  lighting  mockup  or  evaluation 
would  have  been  desirable.  Most  of  the  lighting  evaluation  was  done  by  area  or  analysis,  and  the  re- 
sults were  confirmed  in  the  Orbiter  cabin  built  for  the  Shuttle  Avionics  Integration  Laboratory.  The 
external  lighting  consists  of  metal  halide  lights  for  the  payload  bay  and  incandescent  floodlights 
for  overhead  and  manipulator  illumination.  One  area  of  design  difficulty  with  the  external  lights  is 
the  rejection  of  heat  from  the  lights.  Conductive  cooling  and  innovative  lamp  design  were  required. 

As  the  D&C  requirements  for  the  various  subsystems  continued  to  grow,  the  crew  workload  and 
knowledge  required  of  each  subsystem  grew.  Much  effort  went  into  the  nomenclature  designation  to 
give  the  best  operational  understanding  of  the  use  of  each  control.  This  task  must  have  crew  or  oper- 
ations involvement  because  subsystem  engineers  tend  to  use  engineering  rather  than  operational  nomen- 
clature. 

The  flightcrew  suggested  that  schematic  layouts  on  the  panels  be  considered  for  some  of  the 
subsystems  to  help  understand  their  operation.  Schematic  panel  layouts  were  done  for  panel  R1  (power 
distribution  and  control),  panel  LI  (environmental  control),  panel  L2  (atmospheric  pressure  control), 
panels  07  and  08  (fig.  2)  (reaction  control  and  orbital  maneuvering  systems),  panel  A1  (communi- 
cations), panel  R12  (supply  water),  and  panel  ML31C  (wastewater).  The  use  of  schematic  layouts 
should  be  implemented  only  when  the  subsystems  are  mature  because  once  a panel  is  built,  it  is 
very  difficult  to  add  a switch  in  the  correct  place  of  the  schematic. 

The  HUD  was  brought  back  into  the  program  as  an  approach  and  landing  aid  and  flown  for  the  first 
time  on  STS-6.  From  the  point  of  program  approval  to  hardware  delivery,  a little  more  than  2 years 
elapsed,  a very  tight  time  frame  for  hardware  development,  qualification,  and  delivery.  One  area 
that  proved  to  be  a difficult  problem  was  the  format  development.  Simulations  are  required  using 
both  fixed-  and  motion-base  simulators.  The  simulators  had  to  represent  the  Orbiter  software  as 
closely  as  possible.  One  problem  area  with  the  HUD  display  format  design  effort  was  that  it  came  in 
the  program  with  a ground  rule  to  impact  the  Orbiter  general-purpose  computers  (GPC's)  as  little  as 
possible.  The  HUD  used  the  data  bus  information  going  to  the  dedicated  electromechanical  displays, 
but  the  data  update  rates  were  too  slow.  Therefore,  data  smoothing  had  to  be  done  in  the  HUD  and, 
where  possible,  faster  data  rates  within  the  GPC  were  brought  to  the  HUD.  The  moving-base  simulator 
at  the  NASA  Ames  Research  Center  was  not  available  to  evaluate  the  HUD  format,  except  for  a few 
hours,  before  the  software  programable  read  only  memories  (PROM's)  had  to  be  burned  for  the  hardware. 
The  format  that  was  used  at  this  time  had  a large  amount  of  information  displayed  with  the  capability 
of  decluttering  seven  levels.  The  crew  was  involved  during  all  the  format  design  effort  and,  as  more 
simulations  were  conducted,  it  was  obvious  the  format  had  too  much  information.  A large  effort  using 
fixed-  and  motion-base  simulators  and  the  Shuttle  training  aircraft  (STA)  was  made  and  an  updated, 
simpler  format  was  designed  for  first  use  on  STS-8.  Since  the  hardware  PROM's  had  to  be  built  to  de- 
liver hardware  on  schedule,  a retrofit  program  is  now  in  process  to  update  the  HUD.  One  of  the  rea- 
sons the  HUD  development  went  as  well  as  it  did  was  a series  of  teleconferences  held  every  other  week 
with  JSC,  Rockwell,  Kaiser  Electronics  (HUD  supplier),  Sperry  (autopilot  supplier),  and  Draper  Labs 
(early  systems  support).  These  teleconferences  are  documented  in  a comprehensive  set  of  minutes.  As- 
tronauts and  software,  simulator,  program,  hardware,  and  flight  control  engineers  attend  these 
teleconferences  and  help  provide  integration  of  the  total  HUD  community. 

As  the  Orbiter  became  operational,  it  also  became  obvious  that  the  cockpit  contains  the  most  com- 
plicated assortment  of  D&C  ever  developed  for  an  aerodynamic  vehicle.  There  is  a large  variety  of 
D&C  devices.  For  control,  there  are  toggle,  pushbutton,  thumbwheel,  and  rotary  switches;  potentiom- 
eters; keyboards;  circuit  breakers;  and  hand  controllers.  Display  devices  include  circular  and 
vertical  meters,  tape  meters,  mechanical  talkbacks,  annunciators,  flight  control  meters,  digital 
readouts,  and  CRT's.  There  are  more  than  2100  D&C  devices  in  the  Orbiter  cockpit  (fig.  3). 
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(a)  VIEW  LOOKING  FORWARD. 


(b)  VIEW  LOOKING  AFT. 
FIGURE  3.-  ORBITER  COCKPIT. 
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Orbiter  enhancement  D&C  studies  conducted  recently  have  all  gone  back  to  the  multifunctional 
cockpit  (fig.  4).  To  get  the  systems  operations  to  a more  automated  and  simpler  level  will  greatly  re- 
duce crew  workload.  Multifunction  CRT's  and  flat  panel  displays  could  replace  the  electromechanical 
displays  and  annunciators.  Programable  keyboards  or  CRT  overlays  could  replace  most  of  the  1300  con- 
trol devices.  Remote  power  switching  could  eliminate  many  of  the  400  circuit  breakers.  Voice  con- 
trol and  synthesis  could  be  used  as  an  added  input/output  channel  to  more  efficiently  use  the  crew 
during  peak  workload  periods.  A study  was  conducted  in  the  Manipulator  Development  Facility  (MDF)  to 
assess  the  feasibility  of  using  voice  control  of  the  many  switching  functions  associated  with  the 
closed-circuit  television  system  supporting  the  RMS.  It  was  found  that  identical  tasks  (berthing  and 
deployment)  were  completed  in  virtually  identical  times  using  manual  switching  (standard  Orbiter 
operation)  as  a comparison  for  voice-controlled  switching  having  a recognition  accuracy  between  85 
and  95  percent.  Using  state-of-the-art  voice  recognition  equipment  should  allow  a marked  improvement 
in  the  overall  RMS  operations. 


FIGURE  4.-  MULTIFUNCTIONAL  COCKPIT. 


In  summary,  some  of  the  most  important  lessons  learned  during  the  Orbiter  D&C  program  are  re- 
peated here. 

1.  The  formal  D&C  reviews  held  at  Rockwell  were  necessary.  The  total  Orbiter  systems  community 
needs  to  be  involved;  participation  by  the  flightcrew  and  engineering  personnel  is  very  important. 

The  reviews  should  be  well  documented. 

2.  The  change  package  teleconferences  are  valuable  to  provide  continuous  JSC  input  into  the 
Rockwell  D&C  design  effort. 

3.  D&C  engineers  with  crew  and  human  factors  engineering  support  should  provide  a consistent 
D&C  panel  layout  and  nomenclature  configuration. 

4.  The  early  availability  of  the  foam  core  cabin  mockup  was  very  important  for  D&C  placement 
within  reach  and  visibility  constraints. 

5.  The  HUD  integration  teleconferences  were  necessary,  and  comprehensive  documentation  of  these 
teleconferences  is  important.  Formal  simulations  should  be  done  early  in  the  program  using  high- 
fidelity  simulators. 

6.  With  large  numbers  of  redundant  subsystems,  the  use  of  dedicated  D&C  devices  can  rapidly 
grow  into  a large,  complex  system.  Multipurpose  D&C  should  be  encouraged  with  local  processing  to 
help  offload  the  central  computer  system  and  to  improve  crew  efficiency. 
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ABSTRACT 


The  Huntsville  Simulation  Laboratory  (HSL)  provides  a simulation  facility  to  test  and  verify  the 
Space  Shuttle  Main  Engine  (SSME)  avionics  and  software  system  using  a maximum  complement  of  flight- 
type  hardware.  The  HSL  will  permit  evaluations  and  analyses  of  the  SSME  avionics  hardware,  software, 
control  system,  and  mathematical  models.  It  is  a unique  facility  in  its  authenticity  as  well  as  in 
the  complexity  and  scope  of  simulation.  The  laboratory  has  performed  a wide  spectrum  of  tests  and 
verified  operational  procedures  to  ensure  system  component  compatibility  under  all  operating  condi- 
tions. It  is  a test  bed  for  integration  of  hardware/software/hydraulics.  The  HSL  is  and  has  been 
an  invaluable  tool  in  the  design  and  development  of  the  SSME. 

INTRODUCTION 


Simulation  has  been  an  invaluable  tool  in  design  and  development  of  the  SSME.  Usages  of 
simulation  techniques  are  numerous  and  range  from  component  design  parameter  definition  and  digital 
control  design  to  operating  software  design,  development,  and  verification. 

The  SSME,  three  of  which  provide  primary  thrust  for  the  NASA  Orbiter  vehicles,  incorporates  many 
advanced  features  including  a programmable  digital  control  system  (1).  Control  is  accomplished  with 
an  engine-mounted  electronic  digital  control  system  packaged  in  a single  assembly  called  the 
controller.  The  controller  contains  dual  programmable  computers  with  16,000  memory  words  for  each 
computer.  The  controller,  in  conjunction  with  five  hydraulically  aetuated  propellant  valves,  43 
performance,  limit,  position  and  maintenance  sensor  inputs  and  six  solenoid  control  valves,  accepts 
vehicle  commands  for  the  SSME  operational  phases,  positions  the  appropriate  valves,  monitors  the 
engine  for  performance  conditions  and  provides  redundancy  management  (2  and  3) . The  relationship 
of  the  engine  avionics  to  the  Orbiter  vehicle  is  shown  in  a simplified  manner  in  Figure  1. 

The  SSME  control  system  provides  checkout,  start,  mainstage  operation  and  shutdown  in  response 
to  vehicle  commands.  The  control  system  also  has  the  capability  to  check  out  and  monitor  its  own 
status  and  to  monitor  and  report  engine  status  conditions  while  maintaining  full  redundancy 
management.  The  software  used  by  the  controller  to  accomplish  the  noted  functions  must  be  designed, 
tested  and  verified  to  satisfy  the  system  requirements.  It  is  extremely  important  that  software 
discrepancies  or  errors  be  identified  and  corrected  before  the  software  is  used  by  the  SSME  to  avoid 
engine  or  vehicle  damage. 

The  HSL  located  at  Marshall  Space  Flight  Center  (MSFC)  provides  a program-unique  capability  of 
simulating  SSME  system  operation  at  nominal  and  off-nominal  conditions.  The  simulation  provides  the 
capability  of  perturbating  variables  of  software,  hardware  or  internal  engine  operations  to  determine 
the  SSME  system  response  in  all  modes  of  operation. 

The  present  primary  usage  of  the  HSL  is  the  design,  development,  and  verification  of  the  SSME 
controller  software.  Other  program  uses  of  the  facility  include  systems  integration,  system 
characteristics  definition,  control  system  dynamic  response  definition  and  verification,  and  pro- 
blem resolution  support  to  Kennedy  Space  Center  (KSC)  and  engine  test  sites.  The  operational  soft- 
ware that  is  used  for  SSME  single  engine  testing.  Main  Propulsion  Test  Article  (MPTA)  testing  and 
KSC  flight  vehicle  operation  is  verified  at  the  HSL  prior  to  usage.  Thus  errors  or  conflicts  are 
identified  in  a benign  environment  without  program  impact.  The  SSME  software  is  flown  tens  of  times 
at  the  HSL  before  usage  is  authorized  for  flight  operation. 
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SPACE  SHUTTLE  MAIN  ENGINE 


VEEI 


FIGURE  1 


SIMULATION  FACILITY 


The  need  for  a hardware  simulation  facility  which  incorporated  a maximum  complement  of  avionics 
hardware  was  recognized  early  in  the  SSME  program.  NASA/MSFC  started  the  initial  facility  design 
efforts  in  the  early  1970’ s,  and  the  HSL  was  declared  operational  in  1975. 

The  hardware  simulation  incorporates  as  many  flight  components  and  functional  stimuli  as  are 
practical  for  the  extensive  testing  required  for  system  and  subsystem  analysis,  validation,  and 
verification.  A maximum  hardware  complement  is  used  in  conjunction  with  the  hybrid  simulation  to 
perform  the  following  system  tests: 

a.  Hardware  Integration 

b.  Software  Integration 

c.  Failure  Mode  and  Parameter  Anomaly  Evaluation 

d.  System  Dynamic  Validation 

e.  Sensitivity  Analysis 

f.  Special  Effects  Analysis 

g.  Live  Engine  Correlation 

The  hardware  simulation  must  be  capable  of  cycling  all  phases  of  engine  operation,  including  purge 
sequences,  startup,  mainstage,  shutdown,  and  post -shutdown . 

The  HSL  can  be  divided  into  three  major  elements  as  shown  in  Figure  2.  The  elements  are  the 
engine  dynamic  model,  a complement  of  flight  configuration  hardware,  and  a simulation  control  center. 

Engine  Dynamic  Model  - Hybrid  Computer 

A hybrid  simulation  of  the  SSME  is  programmed  on  two  C 15000  analog  computers  and  one  SEL  840  MP 
digital  computer.  This  simulation  was  developed  from  the  mathematical  models  specified  in  the 
Engine  Balance  and  Dynamic  Model  Specification  (RL00001)  and  the  Engine  Control  Design  Document 
(RSS-8551).  This  simulator  is  programmed  such  that  it  will  operate  independent  of  or  with  any  subset 
of  the  flight-type  hardware  contained  in  the  Simulation  Laboratory  Control  Room.  The  engine,  actu- 
ators, and  sensors  are  simulated  on  the  analog  computers.  The  digital  computer  is  used  to  simulate 
the  main  engine  controller  and  to  handle  initialization  and  timing  functions.  In  the  all-software 
mode,  the  simulation  is  used  to  evaluate  and  validate  the  mathematical  models.  In  the  standard 
operating  mode,  the  hybrid  simulation  supplies  the  engine  internal  pressure  and  temperature  parameter 
values  to  the  Simulation  Control  Room  where  they  are  interfaced  with  the -SSME  Controller,  Figure  3. 

A new  dual  AD-10  digital  simulator  using  a DEC  host  will  be  brought  on-line  to  replace  the  classic 
Hybrid. 

An  engine  simulation  model  of  lower  fidelity  has  been  programmed  on  a PDP  11/34  computer  to 
provide  a backup  to  the  hybrid  simulation.  This  backup  enables  continuation  of  HSL  testing  during 
hybrid  computer  maintenance  operations. 

Flight  Configuration  Hardware 

Flight  configuration  SSME  avionics  hardware  usage  is  maximized  at  the  HSL  to  gain  simulation 
fidelity.  The  major  elements  are  a flight  configuration  SSME  controller  and  propellant  valve 
hydraulic  actuators.  The  SSME  has  five  propellant  control  valves  which  are  hydraulically  actuated 
These  five  hydraulic  actuators  are  incorporated  into  the  simulation  facility  and  integrated  into  the 
control  system  in  the  same  manner  as  they  are  used  by  the  SSME. 

The  HSL  also  includes  spark  igniters,  instrumentation  sensors,  control  solenoids,  propellant 
bleed  valves  and  a pneumatic  control  assembly.  A detailed  list  of  SSME  avionics  hardware  is  in- 
cluded in  Figure  4. 

Simulation  Control  Center 


The  simulation  control  center  interfaces  the  HSL  elements  and  acts  as  the  command  center  for 
testing.  The  center  contains  a Command  and  Data  Simulator  (CADS),  test  consoles,  hydraulic  actu- 
ator load  system,  and  a support  system  consisting  of  data  recording/display  and  diagnostic  tools 
(Figure  3). 


56 


SSME  HSL 


FIGURE  2 


ENGINE  DYNAMIC  MODEL 


HYBRID  COMPUTER 


PUMPS 
TURBINES 
PREBURNERS 
HEAT  EXCHANGERS 
THRUST  CHAMBER 
VALVES 

PROPELLANT  LINES 


DIGITAL  BACKUP 


SSME  HSL 


SIMULATION  CONTROL 
CENTER 


FLIGHT  CONFIGURATION 
HARDWARE 


COMMAND  AND 
DATA  SIMULATOR 


DATA  ACQUISITION 
SYSTEM  - PDP-11 


HISTORY  MEMORY 
SYSTEM 


INTERFACE  UNIT 
AND  TEST  CONSOLES 


SSME 

CONTROLLER 


HYDRAULIC  ACTUATOR 
LOAD  SYSTEM 


■“  SIMULATED  ACTUATORS 


SSME  HYDRAULIC 
ACTUATORS 


SIMULATED  SENSORS 


SSME 

SENSORS 


PNEUMATIC 
CONTROL  ASSY. 


FIGURE  3 


CONTROLLER 

MAIN  FUEL  VALVE  HYDRAULIC  ACTUATOR 
MAIN  OXIDIZER  PREBURNER  VALVE  HYDRAULIC  ACTUATOR 
OXIDIZER  PREBURNER  VALVE  HYDRAULIC  ACTUATOR 
FUEL  PREBURNER  VALVE  HYDRAULIC  ACTUATOR 
CHAMBER  COOLANT  VALVE  HYDRAULIC  ACTUATOR 
SPARK  IGNITERS  (6) 

PRESSURE  SENSORS  (20) 

TEMPERATURE  SENSORS  (10) 

SPEED  SENSORS  (4) 

FLOW  SENSORS  (2) 

OXIDIZER  BLEED  VALVE 
FUEL  BLEED  VALVE 
PNEUMATIC  CONTROL  ASSEMBLY 
SOLENOID  VALVES  (5) 

PRESSURE  ACTUATED  VALVES  (8) 

PRESSURE  SENSORS  (5) 

RECIRCULATION  ISOLATION  VALVE 
GOX  FLOW  CONTROL  VALVE 
HELIUM  PRECHARGE  VALVE 


FIGURE  4 

HSL  SSME  FLIGHT  HARDWARE 


59 


A test  is  initiated  with  commands  from  the  CADS  to  the  SSME  controller,  SSME  actuator  positions 
are  sent  to  the  Engine  Dynamic  Model  which  then  supplies  the  sensor  stimuli  representing  engine 
internal  parameters  to  the  SSME  controller.  The  controller  outputs  data  and  status  to  the  CADS  and 
data  recordings  are  made  for  further  analysis. 

Command  and  Data  Simulator 

The  Command  and  Data  Simulator  (CADS)  contains  a digital  computer  that  interfaces  directly  with 
the  main  engine  controller.  It  is  used  to  simulate  the  Orbiter  vehicle  interface.  The  two  primary 
functions  of  the  CADS  are  to  send  commands  to  the  controller  and  receive  and  record  from  the 
controller. 


Test  Consoles 

Power-up,  testing,  and  monitoring  of  all  simulation  flight  hardware  are  controlled  from  the 
consoles  located  in  the  Simulation  Laboratory  Control  Room.  The  consoles  include  the  capability  of 
fault  insertion.  Manual  switch  control  is  provided  for  SSME  controller  input  and  output  lines.  Thus, 
in  the  case  of  engine  control  parameters,  such  as  thrust  chamber  pressure  where  multiple  sensor  in- 
puts are  used,  failure  insertion  can  be  accomplished  to  fail  maximum,  fail  minimum,  fail  mid-range, 
or  insert  a bias  between  sensor  inputs.  In  the  case  of  propellant  valve  actuators,  the  fault  insert- 
ion can  be  loss  of  command  signal  to  the  actuator  or  loss  of  position  signal  from  the  actuator. 

Hydraulic/Actuator  Load  System 

The  five  primary  propellant  valves  on  the  SSME  are  controlled  by  hydraulic  actuators.  The 
facility  hydraulic  system  provides  3,000  psi  pressure  at  the  SSME  required  flowrate.  Hydraulic 
supply  and  return  lines  are  sized  to  simulate  the  engine  lumped  line  inertia  to  enable  testing  of 
fluid  system  transients.  During  mainstage  operation,  the  actuators  are  under  dynamic  stress  due  to 
the  flow  of  fuel  or  oxidizer  through  their  respective  valves.  In  order  to  simulate  this  loading,  a 
load  actuator  is  coupled  to  each  primary  valve  actuator.  The  load  actuators  are  controlled  by  the 
hybrid  computer  and  can  apply  a physical  load  to  the  primary  valve  actuators  that  is  representative 
of  the  dynamic  loading  that  will  be  experienced  during  actual  engine  operation. 

Simulation  Support  System 

The  HSL  includes  the  following  Simulation  Support  System  to  accomplish  data  recordings,  simulator 
(program)  handling,  input  features,  and  diagnostic  tools: 

a.  Data  Recording 

(1)  Strip-Chart  Recorders 

(2)  Real-Time  Printer 

(3)  Magnetic  Tape 

b.  Data  Display  CRT 

c.  Predetermined  Initialization  Input 

d.  Diagnostic  Software 

e.  PDP/11-34  Computer  for  Data  Analysis 

f.  History  Memory  System 

g.  Power  Transient  Generator 


MAJOR  PROGRAMMATIC  BENEFITS 


Avionics  and  Systems  Integration 

A facility  such  as  the  HSL  enables  the  first-time  integration  of  controls  and  system  in  a 
supportive  test  environment.  The  HSL  has  served  as  the  site  for  initial  integration  of  the  SSME 
controller  to  the  the  control  system  sensors,  hydraulic  actuators,  pneumatic  solenoids,  the  Orbiter 
Engine  Interface  Unit  (EIU),  and  the  Flight  Accelerometer  Safety  Cutoff  System  (FASCOS) . 
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The  FASCOS  development  effort  is  an  excellent  example  of  maximum  utilization  of  simulation 
facilities  for  systems  integration.  The  first  FASCOS  unit  built  was  a rack-mounted  breadboard. 
Following  build  and  laboratory  checkout,  the  FASCOS  breadboard  was  connected  to  a SSME  controller 
for  the  first  time  at  the  HSL.  Initial  testing  verified  interfaces  and  FASCOS  hardware  function. 

The  breadboard  was  then  used  for  development  and  initial  verification  of  the  controller  software. 

A prototype  FASCOS  unit  of  the  engine-mounted  configuration  was  built  and  that  unit  was  also  inte- 
grated with  the  SSME  controller  at  the  HSL.  Formal  verification  of  the  controller  software  was 
conducted  at  the  HSL  using  the  prototype  unit.  The  prototype,  together  with  the  verified  software, 
were  then  exposed  to  single  engine  hot-fire  testing.  Usage  of  simulation  facilities  resulted  in 
of  the  FASCOS  configuration  into  the  SSME  with  avoidance  of  any  delay  at  the  test  site  due  to 
hardware  or  software  integration  problems. 

Integration  tests  have  also  been  conducted  at  the  HSL  to  define  engine  hydraulic  system  pressure 
transients  for  the  Orbiter  system.  These  simulations  of  the  SSME  hydraulic  system  operation  verified 
engine/orbiter  interface  pressure  level  limits  and  worse-case  surge  pressure  transient  response  with 
maximum  propellant  valve  excursion  rates. 

Software  Change  Verification 

The  SSME  control  system  provides  flexibility  due  to  the  programmable  digital  logic.  Thus  changes 
in  operational  sequence,  function,  limits,  and  redundancy  management  can  be  readily  incorporated  as 
knowledge  is  gained  throughout  the  engine  testing  and  flight  operation  program. 

These  software  changes  are  all  subjected  to  verification  testing  at  the  HSL  prior  to  engine 
usage.  The  philosophy  of  change  verification  is  to  expose  the  avionics  hardware  and  software  systems 
to  a simulation  of  the  expected  as  well  as  possible  conditions.  For  example,  if  a change  were  to  be 
desired  in  combustion  chamber  pressure  data  processing  to  enhance  redundancy  management,  verification 
would  require  off-nominal  and  malfunction  conditions  as  well  as  the  expected  operating  profiles.  The 
HSL  verification  of  such  a change  would  entail  normal  start,  mainstage,  throttle  up  and  down,  and 
shutdown  operating  mode  simulations.  Off-nominal  testing  would  involve  simulating  bias  of  sensor 
outputs  and  evaluation  of  control  system  discrimination.  Malfunction  testing  would  involve  simulat- 
ion of  single  and  multiple  sensor  input  failures.  This  testing  would  be  accomplished  using  the 
change  in  conjunction  with  the  operational  software  configuration.  Results  of  these  simulations  are 
evaluated  to  ensure  that  operating  characteristics  and  requirements  of  the  SSME  are  satisfactory. 
Satisfactory  results  can  be  incorporated  into  engine  testing  and  flight  operations.  Conversely,  if 
undesirable  results  are  obtained,  the  software  design  can  be  corrected  without  having  endangered 
engine  or  vehicle  operation. 

Launch  Support  and  Problem  Resolution 

The  HSL  has  proven  a valuable  resource  in  the  prompt  resolution  of  problems  experienced  at  KSC. 
Use  of  the  facility  for  this  purpose  allows  simulation  and  resolution  of  the  problem  and  development 
and  proofing  of  backout  procedures  or  corrections  with  minimum  impact  on  the  operational  site. 

An  example  of  this  was  the  supplementing  of  the  Huntsville  Operational  Support  Center  (HOSC) 
during  the  initial  launch  attempt  for  STS-1.  During  that  operation,  improper  positioning  of  an 
Orbiter  cockpit  switch  resulted  in  generation  of  SSME  Failure  Identifications  (FID's).  Discussion  of 
FID’s  between  the  HOSC  and  HSL  personnel  resulted  in  identification  of  the  probable  cause  as  a SSME 
input  power  failure.  The  HSL  simulated  a power  failure  and  produced  the  identical  FID’s  experienced 
at  KSC.  A procedure  for  restoration  of  power  to  the  SSME  controller  was  developed  and  verified  at 
the  HSL.  HOSC  reviewed  HSL  results  and  concurred  with  the  procedure.  HOSC  communications  with  KSC 
confirmed  the  error  in  switch  positioning,  reported  the  HSL  simulation  results,  and  transmitted  to 
KSC  the  verified  power-up  procedure.  This  entire  scenario  occurred  in  less  than  one  hour  and  avoided 
launch  delay. 

Another  typical  example  occurred  during  preparation  for  FRF-2  for  STS-6.  Engine  position  two 
experienced  two  HALT’S  and  required  usage  of  the  ground  support  equipment  memory  loader  to  recover. 
The  HSL  simulation  capabilities  were  used  to  duplicate  the  HALT  condition  and  to  aid  site  personnel 
in  restoring  SSME  controller  operation.  Further  simulation  testing  at  the  HSL  resulted  in  identifi- 
cation of  the  cause  of  the  HALT  condition,  a correction  for  the  problem  and  a procedure  for  avoid- 
ing the  condition.  Usage  of  the  HSL  in  this  manner  resulted  in  minimization  of  the  time  required  to 
restore  operating  conditions  at  KSC  and  avoidance  of  a schedule  delay  which  would  have  resulted  if 
the  launch  site  had  been  required  for  the  extensive  testing  required  to  identify  the  problem  cause 
and  its  resolution. 
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Engine  System  Malfunction  Analysis 


The  fidelity  of  the  HSL,  including  the  engine  model  and  hardware/software  system  response, 
enables  usage  of  the  facility  for  malfunction  analyses  of  the  SSME  system.  Examples  of  this  usage 
include  evaluation  of  thrust  chamber  coolant  tube  rupture  and  chamber  pressure  sensor  port  blockage 
effects  upon  engine  system  operation. 

In  the  evaluation  of  the  effect  of  a nozzle  tube  rupture,  the  hybrid  computer  analog  model  was 
changed  to  simulate  an  overboard  bleed  flowrate  from  the  thrust  chamber  nozzle  fluid  circuit.  The 
bleed  flowrate  could  be  varied  from  one  to  ten  pounds  per  second.  Flight  simulation  runs  were  then 
conducted  using  varying  bleed  flowrates  to  determine  the  engine  control  system  response,  with  special 
emphasis  on  position  changes  of  the  preburner  valve  actuator  position  relative  to  operating  limits. 

The  simulation  of  the  effect  of  chamber  pressure  sensor  port  blockage  was  accomplished  by  using 
the  test  console  features  which  allowed  biasing  a pair  of  sensor  outputs.  Flight  simulation  runs 
were  then  conducted  using  pre-set  biases  to  determine  the  effect  upon  engine  system  operation. 

FUTURE  APPLICATIONS 


The  HSL  will  continue  to  be  utilized  in  the  SSME  program  in  its  current  role,  with  emphasis  on 
KSC  launch  support  and  software  verification.  Launch  support  responsibilities  will  be  expanded  as 
Vandenberg  Air  Force  Base  (VAFB)  becomes  operational  as  a Space  Shuttle  launch  site. 

SSME  controller  piece  part  obsolescence  has  resulted  in  the  requirements  for  a Block  II  controller 
fpr  future  engine  deliveries.  This  controller  will  require  a different  set  of  software.  Formal 
validation  and  verification  of  the  Block  II  software  will  be  major  HSL  activity  in  the  late  1980 
time  period.  The  flexibility  of  the  HSL  design  will  allow  usage  of  the  facility  to  support  both  sets 
of  software  with  minimal  facility  modification. 
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ABSTRACT 


The  paper  examines  the  background  of  the  Shuttle  avionics  system  design  and  the  unique  drivers 
associated  with  the  redundant  digital  multiplexed  data  processing  system.  With  flight  software 
pervading  to  the  lowest  elements  of  the  flight-critical  subsystems,  it  was  necessary  to  identify 
a unique  and  orderly  approach  of  verifying  the  system  as  flight-ready  for  STS-1.  The  approach 
and  implementation  plan  is  discussed,  and  both  technical  problems  and  management  issues  are  dealt 
with.  A summary  of  "lessons  learned"  completes  the  presentation. 


BACKGROUND 

Before  addressing  the  subject  of  this  paper,  it  would  be  worthwhile  to  summarize  the  salient  fea- 
tures of  the  Shuttle  avionics  system  in  preparation  for  the  subsequent  discussion  (fig.  1). 
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1.  The  primary  flight  system  (PFS)  design  is  based  on  a centralized  set  of  quad-redundant  gen- 
eral-purpose computers  (GPC's)  within  the  data  processing  system  (DPS)  which  provides  the  primary 
mode  of  acquiring  flight-critical  sensor  data,  processing  the  data,  and,  finally,  generating  and 
delivering  guidance,  navigation,  and  control  (GN&C)  commands  to  the  various  vehicle  control  elements 

(fig.  2). 


2.  Additionally,  a single  GPC  with  independently  designed  and  coded  flight  software,  called  the 
backup  flight  system  (BFS),  is  available  to  take  over  vehicle  control  through  the  primary  bus  struc- 
ture from  the  PFS,  if  necessary. 

3.  The  DPS  bus  structure  contains  24  separate  serial  digital  input/output  (I/O)  buses  including 
8 flight-critical  (GN&C)  and  5 intercomputer  (ICC)  buses,  which  provide  for  sensitive  data  communica- 
tions and  control  through  the  GPC  redundant  set. 

4.  The  various  multiply  redundant  inertial  navigation  and  flight  control  sensors  and  effectors 
must  be  in  a constant  state  of  readiness  to  perform  the  fault  detection,  isolation,  and  reconfigura- 
tion (FDIR)  functions. 

5.  The  avionics  and  nonavionics  system  management  (SM)  function  is  performed  in  conjunction 
with  the  operational  instrumentation  (01). 

6.  A three-string  electrical  power  distribution  and  control  system  provides  single  fault- 
tolerant  power  to  non-flight-critical  systems  and  dual  fault-tolerant  power  to  flight-critical  sys- 
tems (fig.  3). 
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FIGURE  2.-  ORBITER  DATA  PROCESSING  SYSTEM. 


65 


j}-  POWER  CONTRACTOR/RELAY 

FIGURE  3.-  ORBITER  POWER  DISTRIBUTION,  SINGLE  STRING. 


During  the  early  years  of  the  Space  Shuttle  Program,  the  avionics  system  was  defined  and  under- 
stood with  regard  to  design  requirements  from  the  top  downward,  and  it  was  assumed  that  the  methods 
used  for  system  certification  during  the  Apollo  Program  would  suffice  for  the  Shuttle.  However,  it 
became  apparent,  as  the  various  subsystem  designs  matured,  that  software  would  be  increasingly  domi- 
nant in  the  system  functions.  In  fact,  the  flight  software  would  pervade  throughout  multiple  levels 
of  the  various  elements  as  evidenced  in  the  GN&C  system  (fig.  4). 

With  the  significant  improvements  in  capability  of  digital  flight  computers,  the  increasing  im- 
portance of  software  within  a hardware  design  was  not  unexpected.  The  unexpected  factor  was  the  time 
phasing  of  the  software  code  design  and  development,  which,  because  of  the  need  to  understand  first 
the  hardware  design  and  operating  characteristics,  lagged  behind  the  hardware  in  subsystem  test  readi- 
ness. A significant  dilemma  that  emerged  was  a means  of  testing  and  certifying  the  lower  level  sub- 
system elements  in  a reasonable  time  phase  in  the  program  with  already  developed  hardware  and  imma- 
ture flight  software. 

The  complexity  of  the  problem  became  apparent  during  laboratory  testing  of  the  various  avionics 
subsystems  which  were  to  be  employed  in  the  Orbiter  101  (Enterprise)  Approach  and  Landing  Test  (ALT) 
Program  at  Edwards  Air  Force  Base  in  1977.  During  the  laboratory  test  period,  which  preceded  the 
flights  by  a year,  concern  was  generated  because  of  confusion  arising  in  the  following  areas. 

1.  The  scope  of  hardware  certification,  which  generally  was  thought  to  be  stand-alone  line  re- 
placeable unit  (LRU)  (i.e.,  black  box)  testing,  and  its  relationship  with  subsystem-  and  system- 
level  function  and  performance  testing,  usually  requiring  some  of  the  flight  software  elements  in  com- 
bination  with  hardware  LRU's 

2.  The  scope  of  testing  necessary  to  declare  the  system  ready  to  fly  as  compared  to  the  test 
and  analysis  necessary  to  provide  specification  compliance 

3.  Visibility  of  the  requirements  to  meet  both  flight-readiness  and  specification  compliance 
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In  1978,  following  the  ALT  Program,  several  members  of  Rockwell  and  NASA  engineering  management 
met  for  the  purpose  of  addressing  the  previously  mentioned  problems  before  the  onset  of  Orbital 
Flight  Test  (OFT)  preparations.  At  the  meeting,  it  was  decided  (1)  to  modify  the  scope  and  relation- 
ship of  the  Orbiter  LRU  certification  and  necessary  subsystem-  and  system-level  avionics  tests  and 
analyses,  hereinafter  called  verification,  (2)  to  differentiate  between  mission-to-mission  flight 
readiness  during  OFT  and  operational  readiness  indicated  by  specification  compliance,  and  (3)  to  de- 
velop a mission-to-mission  verification  process  with  adequate  rigor  and  visibility  necessary  to  iden- 
tify the  specific  requirements  to  meet  flight  readiness  during  OFT. 


GENERAL  APPROACH 


To  establish  a verification  process,  it  was  first  necessary  to  establish  the  relationship  be- 
tween hardware  and  software.  In  the  case  of  the  Orbiter  DPS,  flight  software  elements  which  were  com- 
monly resident  in  the  GPC's  supported  the  lowest  level  hardware  LRU's.  To  treat  these  software  ele- 
ments, which  effectively  stand  alone  in  function,  and  their  hardware  LRU  counterparts  as  functioning 
subsystems,  the  software  elements  were  also  called  LRU's.  Simply  stated,  verification  may  be  de- 
fined as  higher  level  tests  and  analyses  above  the  LRU  certification  level  necessary  for  compliance 
with  predefined  requirements.  For  purposes  of  Shuttle  avionics  verification,  the  various  levels 
range  from  the  lowest  stand-alone  functional  element  (actuation  subsystem)  to  the  highest  level  of 
integrated  vehicle  elements  (mated  Shuttle  vehicle),  as  shown  in  figure  5.  This  definition  also 
infers  that  the  avionics  verification  process  would  transcend  project-level  boundaries  between 
the  various  vehicle  elements  and  would,  indeed,  be  an  integrated  avionics  verification  process. 
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As  a result  of  the  1978  discussions,  it  became  apparent  that  it  was  neither  necessary  nor  possi- 
ble to  complete  all  verification  tests  and  analyses  required  to  achieve  specification  compliance 
before  the  first  OFT  flight  (STS-1).  Instead,  it  was  decided  to  address  flight-readiness  verifica- 
tion on  a mission-by-mission  basis.  The  cumulative  mission  verification  effort  coupled  with  a de- 
fined analytical  effort  became  the  building  blocks  to  complete  specification  compliance  verifica- 
tion (fig.  6).  Finally,  it  was  evident,  because  of  the  system  complexity,  that  a highly  visible  and 
rigorous  process  must  be  in  place  to  assure  that  the  necessary  tests  and  analyses  had  been  completed 
to  provide  confidence  in  declaring  system  flight  readiness. 


FIGURE  5.-  SHUTTLE  LRU  CERTIFICATION  AND  SUBSYSTEM- 
ANO  SYSTEM-LEVEL  VERIFICATION. 


FIGURE  6.-  RELATIONSHIP  OF  FLIGHT -READINESS 
VERIFICATION  TO  TOTAL  VEHICLE  SPECIFICATION 
COMPLIANCE  VERIFICATION. 


In  the  case  of  the  DPS  and  the  GN&C  system,  the  design  teams  were  in  place  and  were  sensitive  to 
the  relationship  of  their  respective  technical  disciplines  with  the  integrated  avionics  system.  This 
was  not  necessarily  the  case  for  the  nonavionics  disciplines,  for  which  sequencing,  control,  and  sys- 
tem management  functions  for  power  generation,  mechanical,  and  propulsion  systems  were  provided  as  a 
service  by  the  DPS.  To  provide  verification  requirements  visibility  within  the  nonavionics  systems, 
three-man  subsystem  teams,  consisting  of  one  each  software,  hardware,  and  test  specialist  familiar 
with  each  of  the  subsystem  designs,  were  formed.  They  were  responsible  for  using  the  various  sub- 
system specification  and  design  documents  to  define  a bottom-upward  approach  to  the  verification 
requirements. 

In  the  case  of  all  systems,  as  the  requirements  were  identified,  they  were  mapped,  using  as  a 
reference  hardware,  drawings,  software  specifications,  certification,  qualification  test,  acceptance 
test  plans,  and  designer  insight.  The  resulting  "roadmap"  identified  the  type  of  analysis,  labora- 
tory, and/or  flight  vehicle  test  necessary  to  accomplish  verification  for  that  specific  element,  func- 
tion, or  subsystem.  Each  roadmap  stood  alone  but  provided  the  foundation  for  higher  level  elements 
in  the  verification  tree  (fig.  7).  Each  roadmap  evolved  into  a verification  plan  which  was  jointly 
negotiated  between  the  Rockwell  sponsor  responsible  for  design  and  acceptance  in  the  respective  tech- 
nical discipline  and  the  NASA  counterpart.  Tests  and  analyses  were  conducted  and  results  jointly 
reviewed  by  the  sponsors.  The  final  conclusions  were  documented  in  a Verification  Completion  Notice 
(VCN) , which  was  signed  by  the  sponsor  counterparts.  The  resulting  documentation  (verification  plan, 
VCN,  and  associated  test  and  data  requirements  documents)  provided  the  desired  rigor  and  traceability 
to  the  process. 

In  summary,  the  role  of  the  technical  sponsors  was  the  keystone  to  the  verification  process. 

Each  was  charged  with  the  responsibility  of  defining  the  verification  requirements,  determining  the 
method  of  test  or  analysis  to  meet  requirements,  defining  the  criteria  for  test  site  acceptance, 
determining  the  data  requirements  for  the  tests,  determining  the  pass-fail  criteria  for  those  data, 
resolving  test  anomalies,  reporting  the  test  results,  and,  finally,  determining  the  flight  readiness 
of  his  function  or  element.  It  is  now  appropriate  to  describe  the  technical  and  management  tools  nec- 
essary to  make  the  verification  process  work. 
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FIGURE  7.-  OFT  FLIGHT-READINESS  VERIFICATION  PROCESS. 
DESIGN  VERIFICATION  APPROACH 


The  avionics  design  verification  approach  employed  the  following  methodology. 

1.  Divide  the  total  avionics  system  into  technical  disciplines. 

2.  Utilize  the  best  technical  resources  for  verification;  i.e.,  assign  the  best  technical  per- 
sonnel as  verification  sponsors  for  each  technical  discipline  and  determine  the  best  combination  of 
test  and  analysis  tools  for  the  job. 

3.  Establish  a framework  for  avionics  integration. 


Figure  5 shows  the  application  of  this  logic  tree  process  to  the  lowest  levels.  As  a basis  for  the 
verification,  the  sponsors  treated  both  the  hardware  and  the  software  LRU's  as  flightworthy  elements; 

i.e.,  the  hardware  LRU's  were  certified  to  withstand  the  flight  environments,  and  software  was  in- 
dependently tested  to  show  requirements  compliance. 

The  sponsor's  challenge  was  to  demonstrate  the  f 1 ightworthiness  of  his  respective  hardware 
or  software  element  to  accomplish  the  mission.  The  following  tools  were  used  as  appropriate. 

1.  Hardware  and  software  laboratories  and  test  facilities 

2.  Analysis  programs 

3.  Airborne  test  articles 

4.  Shuttle  flight  vehicle  prelaunch  testing 

The  use  of  the  flight  vehicle  was  very  restricted.  The  strategy  was  to  perform  the  bulk  of  verifica- 
tion through  laboratory  testing  and  analysis. 
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HARDWARE  AND  SOFTWARE  LABORATORIES  AND  TEST  FACILITIES 

The  Flight  Systems  Laboratory  (FSL)  at  Downey,  California  (fig.  8),  and  the  Shuttle  Avionics  In- 
tegration Laboratory  (SAIL)  at  the  NASA  Lyndon  B.  Johnson  Space  Center  (JSC),  Houston,  Texas  (fig. 

9),  had  been  developed  as  the  primary  test  facilities  for  avionics  verification.  Because  of  avionics 
system  complexity  and  for  schedule  considerations,  the  SAIL  was  developed  for  the  ascent  flight  phase 
and  the  FSL  was  developed  for  the  descent  flight  phase.  The  FSL  and  the  SAIL  shared  the  on-orbit  ver- 
ification. Both  facilities  provided  system-level  open-  and  closed-loop  capability,  and  SAIL  possessed 
a complete  set  of  flight-type  avionics  hardware  and  cable  harnesses. 

Other  hardware  test  facilities  included  the  Flight  Control  Hydraulic  Laboratory  (FCHL) , the  JSC 
Electronics  Systems  Test  Laboratory  (ESTL),  Thiokol,  the  Main  Propulsion  Test  Article  (MPTA),  and  the 
NASA  George  C.  Marshall  Space  Flight  Center  (MSFC)  Main  Engine  Simulator.  Using  these  facilities, 
the  sponsor  would  typically  develop  and  validate  math  models,  establish  open-  and  closed-loop  func- 
tion and  performance,  and  confirm  hardware-to-hardware  and  hardware-to-software  compatibility. 

Before  a facility  was  used  for  formal  verification,  the  sponsors  performed  site  acceptance  testing 
using  off-line  analytical  data  as  a reference.  Site  acceptance  provided  sponsor  confidence  in  facil- 
ity representation  of  the  flight  article. 


ANALYSIS  PROGRAMS 

The  sponsors  used  analysis  programs  to  confirm  stability  and  to  verify  dynamic  performance 
considering  nominal  and  off-nominal  conditions.  The  sponsors  developed  the  analysis  programs  in  par- 
allel with  the  system  design,  development,  and  verification  testing.  The  fidelity  of  the  analysis 
programs  was  updated  by  correlating  their  performance  with  test  results.  Eventually,  the  analysis 
programs  became  key  off-line  analysis  tools  that  could  repeat  test  results  and  expand  operating  condi- 
tions by  parametric  changes  to  establish  envelopes  about  the  design  nominal.  These  analysis  tools  ef- 
fectively supplemented  the  hardware  test  articles  for  complete  system  verification. 


FIGURE  8.-  FLIGHT  SYSTEMS  LABORATORIES. 
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FIGURE  9.-  SHUTTLE  AVIONICS  INTEGRATION  LABORATORY. 


AIRBORNE  TEST  ARTICLES 

The  Shuttle  Training  Aircraft  (STA)  and  the  SR71  flight  test  program  supplemented  avionics  veri- 
fication by  providing  in-flight  characteristics  to  enhance  sponsor  understanding.  Limited  but  valu- 
able flight  insights  were  derived  through  use  of  this  technique. 


SHUTTLE  FLIGHT  VEHICLE  PRELAUNCH  TESTING 

Ground  testing  of  the  actual  vehicle  to  be  flown  provided  an  extremely  beneficial  understanding 
of  specific  flight  vehicle  characteristics.  In  addition  to  the  rigorous  ground  checkout  process, 
which  was  an  independent  key  element  for  committing  to  flight,  specific  verification  ground  tests 
were  accomplished  on  the  flight  vehicle.  These  tests  required  a higher  level  of  assembly  and  integra- 
tion than  could  prudently  be  accomplished  in  a laboratory.  End-to-end  flight  control  tests,  dynamic 
stability  verif ication,  and  simulated  integrated  mission  runs  were  typical  types  of  tests.  Because 
these  tests  used  both  flight  hardware  and  flight  software,  extremely  high  preflight  confidence  in  the 
integrity  of  the  flight  article  was  obtained. 

To  complete  the  framework  for  the  avionics  integration,  a challenge  emerged  which  required  the 
NASA  and  contractor  institutional  managers  to  coordinate  their  various  technical  resources  and  meet 
a time-critical  flight-readiness  schedule. 
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MANAGEMENT  CHALLENGE 


Because  the  various  elements  of  the  integrated  avionics  system  were  being  developed  by  three 
NASA  field  centers  and  numerous  contractors,  it  was  necessary  to  provide  some  means  of  unified  con- 
trol. The  myriad  of  diverse  program  elements  (fig.  10)  had  to  be  integrated  by  a process  capable  of 
developing  the  confidence  necessary  to  ensure  that  the  avionics  hardware  and  software  system  was 
ready  for  flight  within  a defined  time  schedule.  The  control  mechanism  had  to  be  capable  of  provid- 
ing communication  among  the  various  program  elements,  system  technical  areas,  and  program  management. 
It  also  had  to  be  capable  of  controlling  all  aspects  of  the  avionics  verification  process  without 
restricting  the  feeling  of  personal  accountability.  In  addition  to  providing  for  program  biases,  the 
management  function  also  had  to  be  responsible  for  assuring  availability  of  the  tools  necessary  for 
providing  the  test  and  the  analysis  data  base  required  for  proof  of  system  flight  readiness. 

Taking  into  account  these  fragmented  but  critical  activities,  the  complexity  of  the  avionics  sys- 
tem, and  the  magnitude  of  verification  requirements,  it  was  necessary  that  specific  management  con- 
trols be  provided.  These  included  the  following. 

1.  Obtain  and  maintain  the  commitment  from  the  technical  sponsors  to  do  the  verification  job. 

2.  Provide  interface  between  the  program  elements. 

3.  Allocate  test  facility  resources. 

4.  Resolve  issues. 

5.  Secure  fl ight- readiness  commitment  from  the  sponsors. 

6.  Provide  program  management  with  focused  visibility  of  verification  progress  and  bring  forth 
unresolved  issues. 


LEVEL H 
LEVEL  ID 
JSC/KSC/MSFC 
PROGRAM  ELEMENTS 


SPONSORS  MSFC  TOOLS 

FIGURE  10.-  MANAGEMENT  CHALLENGES. 
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Early  in  1978,  the  avionics  verification  management  was  established  to  provide  these  controls.  It 
encompassed  all  aspects  of  avionics  verification  and  was  focused  through  a management  review  team, 
which  presided  over  and  administered  the  avionics  verification  activities.  The  team  consisted  of  man- 
agers from  each  aspect  of  avionics  verification,  as  follows. 


Management  Working  Group  (MWG)  Membership 


NASA 


Rockwell 


Systems  Engineering 
SAIL 

NASA  John  F.  Kennedy  Space  Center  (KSC)  Engineering 

GN&C  Engineering 

Flight  Software  Engineering 


Systems  Engineering 

FSL 

SAIL 

KSC  Engineering 


The  MWG  was  provided  with  tools  to  assure  their  ability  to  control  the  process.  These  tools 
consisted  of  the  following. 


VERIFICATION  LOGIC  TREE 

The  verification  logic  tree  (fig.  11)  defined  the  scope  of  avionics  verification.  It  provided 
a single  source  to  relate  the  individual  subsystem  function  to  other  elements  in  the  integrated 
avionics  system.  Each  subsystem  function  is  depicted  in  a block  on  the  tree;  relationships  of  sub- 
functions are  listed  below  each  block.  The  tree  provides  a "bottom-up"  hierarchy  of  subsystem  func- 
tions (such  as  flight  control)  to  the  higher  functions  (such  as  descent  GN&C)  and  then  to  the  top 
function  (integrated  avionics).  The  verification  logic  tree  provided  a reference  tool  with  which 
to  measure  the  verification  progress,  to  establish  priorities,  and  to  determine  areas  requiring 
additional  emphasis. 
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INDIVIDUAL  ACCOUNTABILITY  MATRIX 


Related  to  the  verification  tree  was  the  matrix  of  sponsor  accountability.  As  previously  men- 
tioned, success  of  the  verification  process  depended  on  the  involvement  of  the  avionics  system  de- 
sign personnel.  This  involvement  was  assured  by  developing  an  accountability  matrix  based  on  the 
verification  logic  tree  and  assigning  the  appropriate  NASA  and  Rockwell  counterparts  to  each  sub- 
system or  function  and  by  obtaining  commitments  from  line  management  that  avionics  verification 
sponsorship  was  truly  the  individual’s  assigned  task.  In  other  words,  the  process  was  totally 
reliant  on  the  design  community  for  the  technical  effectiveness  of  avionics  verification.  With- 
out the  commitment  of  the  proper  personnel  to  the  process  and  the  backing  of  the  process  by  pro- 
gram management,  it  would  not  have  been  possible  to  integrate  and  manage  the  effort  required  for 
commitment  to  flight  readiness. 


MANAGEMENT  WORKING  GROUP 

The  MWG  was  the  forum  for  administering  the  avionics  verification  process.  It  met  weekly  by 
teleconference  to  review  progress  of  avionics  hardware  and  software  system  verification  and  to  re- 
solve issues  impacting  the  process  as  shown  in  figure  12.  Specifically,  the  functions  of  the  MWG 
were  as  follows. 

1.  Review  and  baseline  the  verification  tests  for  each  flight. 

2.  Review  and  approve  changes  to  the  baseline  for  new  requirements  (mission  changes,  software 
changes,  or  delivery  schedules). 

3.  Establish  test  priorities. 

4.  Review  laboratory  schedules. 
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FIGURE  12.-  VERIFICATION  PROCESS  FLOW  AND  DOCUMENTATION  SUMMARY. 
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5.  Identify  laboratory  problems,  hardware  availability  issues,  and  manpower  assignments  that 
must  be  taken  to  program  management  for  resolution. 

6.  Review  verification  issues. 

The  MWG  provided  the  medium  for  sponsor  interface  with  the  laboratories,  JSC,  KSC,  and  MSFC.  The  MWG 
was  co-chaired  by  Rockwell  and  NASA,  and  decisions  of  the  MWG  Board  constituted  direction  to  the  veri- 
fication community  to  proceed.  Any  issues  which  carried  impacts  beyond  the  verification  community 
were  taken  forward  to  program  management  for  disposition. 


FLIGHT  READINESS  VERIFICATION  PLANS 

The  Flight  Readiness  Verification  Plans  (FRVP's)  provided  traceability  to  the  sponsor's  verifica- 
tion requirements  and  consisted  of  three  parts:  (1)  verification  roadmaps,  (2)  verification  require- 

ments, and  (3)  an  approval  sheet.  The  verification  roadmap  identified  the  verification  tasks,  the 
test  site,  and  the  planned  schedule  for  the  tests.  The  verification  requirements  sheet  defined  each 
verification  task  in  general  terms  and  assigned  a tracking  number  to  each  task.  The  tracking  number 
was  used  to  provide  traceability  from  the  VCN  back  to  the  FRVP.  The  approval  sheet  was  signed  by 
Rockwell  and  NASA  counterparts  after  the  plan  and  the  details  had  been  coordinated.  The  FRVP,  in 
conjunction  with  the  verification  logic  tree,  defined  the  total  task,  which,  when  completed,  would 
provide  a data  base  sufficient  to  permit  signoff  at  each  level  of  the  commit-to-f light  process. 

These  two  documents  provided  the  MWG  with  the  necessary  criteria  for  evaluation  of  the  criticality 

of  remaining  effort. 


SUMMARY  - WITH  REFLECTIONS 


The  resulting  verification  process  culminated  in  an  intense  but  orderly  effort  which  provided 
the  necessary  confidence  in  the  Space  Shuttle  avionics  system  to  perform  the  STS-1  mission.  The  proc- 
ess remains  in  place  today  and  is  providing  the  necessary  incremental  verification  to  determine 
flight  readiness  for  subsequent  flights. 

Throughout  the  effort  leading  to  the  first  flight,  the  process  provided  the  means  for  success- 
fully resolving  the  conflicts  which  occurred  during  the  integration  of  this  complex  system.  Typical 
were  the  significant  problems  discovered  within  the  Orbiter  entry  flight  control  system  during  ini- 
tial verification  testing.  A resulting  major  redesign  within  the  flight  software  required  major 
replanning  and  schedule  changes.  During  this  period,  the  working  relationships  among  the  verifica- 
tion sponsors  (designers),  the  laboratory  test  teams,  and  the  flight  software  design  and  test  person- 
nel led  to  mutual  respect  for  the  common  objective:  "Get  the  avionics  system  ready  to  fly!"  Their 

commitment  to  that  objective  minimized  the  conflicts  that  had  to  be  resolved.  Had  management,  early 
in  the  program,  understood  the  impacts  of  software  involvement  throughout  the  avionics  system,  the 
logjam  of  concurrent  subsystem-  and  system-level  testing  resulting  from  late  release  of  flight  soft- 
ware might  have  been  minimized.  As  it  was,  the  process  lessened  the  logjam  by  integrating  subsystem 
requirements  into  system- level  test  runs.  The  message,  however,  remains:  "In  future  programs,  the 

subsystem  designs  should  acknowledge  the  need  for  an  up-front  verification  strategy  which  minimizes 
the  labor-intensive  laboratory  test  effort." 

Finally,  the  need  to  involve  the  designer  personally  in  the  flight-readiness  verification  proc- 
ess for  future  programs  needs  to  be  acknowledged.  This  involvement  includes  not  only  the  planning 
phases  of  the  verification  but  also  the  final  decisions  of  system  flight  readiness.  With  the  in- 
creased interaction  of  future  flight  systems,  the  individual  designers  must  be  accountable  for  the 
readiness  of  their  respective  elements  for  flight. 
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ABSTRACT 


This  paper  discusses  the  challenges  presented  by  the  concept  of  a reusable,  cargo  carrying  space 
vehicle,  and  how  those  challenges  were  met  for  the  Space  Shuttle.  Areas  discussed  here  include  the 
complexity  of  the  vehicle,  the  ground  support  system,  the  onboard  computer  system,  ramifications  of 
a reusable  vehicle,  and  the  turn-around  objectives  for  Shuttle  flights. 

After  six  successful  flights  at  the  time  of  this  writing,  it  can  be  safely  said  that  the  chal- 
lenges presented  here  have  been  basically  met. 


INTRODUCTION 

Adjacent  to  the  Vertical  Assembly  Building  (VAB)  at  Kennedy  Space  Center  (KSC)  is  an  APOLLO  vehi- 
cle, complete  with  all  the  stages  required  to  orbit  the  Moon  and  return.  The  long,  sleek  and  sharply 
pointed  configuration  could  be  imagined  to  be  a spear  used  by  some  mythological  god  to  fling  into  the 
heavens  to  bring  down  a passing  star. 

In  the  VAB,  in  preparation  for  a Space  Transportation  System  (STS)  flight  is  a configuration  of 
two  Solid  Rocket  Boosters  (SRBs),  an  External  Tank  (ET),  and  an  Orbiter.  Unlike  the  APOLLO  launch 
configuration,  the  STS  looks  bumpy,  unsymmetrical , and  no  god  would  have  any  use  for  it.  Indeed,  the 
STS  configuration  could  be  thought  of  as  the  bumblebee  of  space  flight  - it  appears  to  be  an  ill- 
conceived  design,  but  does  its  job  beautifully. 

Although  the  appearance  of  the  two  vehicles  is  remarkably  different,  the  technical  aspects  of 
preparing  each  for,  and  accomplishing  a launch  are  even  more  different.  This  article  will  present 
some  comparisons  in  vehicle  complexity,  ground  support  systems,  objectives,  and  turn-around  require- 
ments to  demonstrate  how  the  STS  challenges  were  responded  to. 


VEHICLE  COMPLEXITY 

As  stated  earlier,  the  appearance  of  STS  is  very  different  from  its  predecessors  in  America's 
space  ventures.  The  STS  is  several  orders  of  magnitude  more  complex  than  earlier  launch  vehicles. 
Indeed,  STS  is  the  first  vehicle  conceived,  designed,  and  implemented  strictly  as  a space  transpor- 
tation system.  Earlier  vehicles  used  to  put  payloads  into  space  were,  at  best,  quasi-mil itary  in  con- 
cept and  design,  and  in  some  cases  such  as  Thor,  Atlas,  Delta,  etc.  were  military  vehicles  adapted 
for  use  by  NASA. 

Several  items  may  be  compared  between  APOLLO  and  STS  to  demonstrate  the  increased  complexity  of 
the  vehicle:  engines,  control  capability,  computers,  payloads,  and  landings. 


Engines 

The  APOLLO  vehicle,  although  consisting  of  three  stages,  can  be  thought  of  as  a single  engine  ve- 
hicle, since  only  one  type  of  engine  was  ignited  at  a time.  Even  in  the  Saturn  V first  stage  with 
its  five  engines,  the  engines  were  arranged  symmetrically  about  the  center  of  the  vehicle  with  the  mid- 
dle engine  fixed. 

The  STS,  in  a nominal  launch,  also  has  five  engines  ignited.  However,  two  of  these  are  SRBs, 
while  three  are  the  Space  Shuttle  Main  Engines  (SSME);  and  the  engines  are  not  symmetrical  about  the 
centerline  of  the  total  vehicle. 

The  SSME's  are  liquid  fueled  from  the  ET  and  controlled  by  their  own  computer  (Engine  Control- 
ler) which  interfaces  with  the  onboard  computer  system,  while  the  SRBs  are  solid  fueled  and  con- 
trolled directly  by  the  onboard  computer  system. 

In  some  non-nominal  situations,  the  STS  can  also  utilize  the  two  Orbital  Maneuvering  System 
(OMS)  engines  to  assist  in  later  stages  of  the  launch.  These  engines  are  liquid  fueled  from  tanks 
onboard  the  Orbiter. 
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Control  Capability 


In  APOLLO,  the  astronauts  were  "along  for  the  ride"  - that  is,  the  launch  and  ascent  were  auto- 
matically controlled  by  the  ground  and  onboard  computer.  The  crew  had  very  few  options  if  trouble 
developed  during  the  ascent  into  Earth  orbit. 

The  STS  has  both  automatic  control  and  manual  control.  The  automatic  control  is  similar  to 
APOLLO.  The  manual  control  allows  the  pilot  to  manually  steer  the  vehicle  using  the  Rotational  Hand 
Controller  (RHC)  from  SRB  ignition  through  SSME  shutdown. 

The  STS  also  has  the  capability,  for  non-nominal  situations,  of  several  abort  modes:  a Return- 

to-Launch-Site  (RTLS),  a Trans-Atl antic  Landing  (TAL),  an  Abort-Once-Around  (AOA),  and  an  Abort-to- 
Orbit  (ATO). 


Computers 


The  APOLLO  configuration  contained  a single  computer  in  the  Instrumentation  Unit  which  con- 
trolled the  vehicle's  flight.  The  computer  was  preloaded  with  the  flight  profile,  data,  etc.  and, 
for  ascent,  had  no  crew  interface  capability. 

STS,  on  the  other  hand,  has  five  General  Purpose  Computers  (GPCs)  which  control  the  vehicle's 
flight  and  provide  interfaces  to  the  crew  to  allow  them  to  make  inputs  during  ascent.  Four  of  the 

computers  run  in  a "redundant  set"  using  the  Primary  Avionics  Software  System  (PASS),  while  the  fifth 

is  loaded  with  the  Back-up  Flight  System  (BFS).  During  ascent  the  four  PASS  computers  synchronize 
themselves  over  300  times  per  second  and  pass  data  to  the  BFS  computer  to  allow  it  to  track  the 

flight.  Should  the  PASS  set  fail,  the  crew  can  order  the  BFS  computer  to  take  command  and  provide 

for  a safe  flight  to  either  continue  or  return. 


Payloads 

APOLLO  was  designed  to  put  a single  payload  into  space  - the  crew  compartment  (and  Lunar  Excur- 
sion Module)  and  its  contents.  It  was  strictly  an  exploration  program  to  increase  our  knowledge  of 
near  space  through  manned  exploration. 

STS  is  a service  system  designed  to  put  many  types  of  payloads  into  space.  With  its  Remote  Mani- 
pulator System  (RMS),  or  "arm",  STS  can  deploy  and  retrieve  payloads,  shuttle  them  back  and  forth, 
and  perhaps  even  effect  repairs  on  faulty  payloads  in  orbit. 


Landings 

The  APOLLO  crew  compartment  effected  a ballistic  reentry  with  a water  landing  where  it  was 
plucked  from  the  water  by  a ship  stationed  in  the  landing  zone,  then  transported  back  to  the  USA  for 
display. 

The  STS  lands  in  a conventional  aircraft  manner  on  a landing  strip  using  conventional  areosur- 
face  controls  such  as  elevons,  rudder,  and  speedbrake,  with  retractable  landing  gear.  It  can  then 
be  readied  for  the  next  launch. 


GROUND  SUPPORT  SYSTEMS 

The  ground  support  systems  of  APOLLO  and  STS  are  as  different  in  nature  and  complexity  as  the  ve- 
hicles themselves  are.  Indeed,  the  consoles  of  the  STS  ground  system  are  said  to  be  inverted  APOLLO 
ground  system  consoles! 


Apollo  Ground  Support  System 

The  APOLLO  ground  support  system  was  composed  of  two  ground  computers  which  were  transistorized, 
large  scale,  serial,  digital  computers.  One  computer  was  located  in  the  Launch  Control  Center  (LCC) 
and  communicated  via  a data  link  with  the  other  computer  in  the  Mobile  Launcher. 

The  two  computers  were  required  to  be  on-line  and  operational  for  checkout  and  launch  so  there 
was  very  little  redundant  or  backup  hardware.  There  were  numerous  single-point  failures,  and  nearly 
50  percent  of  the  hardware  was  located  within  a few  hundred  feet  of  the  vehicle,  creating  hazardous 
areas  for  maintenance. 
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More  than  two  hundred  people  were  required  to  monitor  the  meters,  lights,  plotters,  etc.  used 
in  the  launch  complex  to  checkout  and  launch  the  vehicle.  Data  was  obtained  through  fixed  telemetry 
streams  and  fed  into  the  LCC  for  interpretation  by  the  individual  engineers. 

Testing  of  the  launch  configuration  was  largely  a serial  operation.  A particular  subsystem 

would  have  to  be  fully  tested  before  the  next  subsystem  could  be  started. 

The  net  effect  of  this  system  was  a long,  tedious  process  to  ready  the  launch  vehicle  for 
flight. 


STS  Ground  Support  System 

The  STS  ground  support  system,  termed  the  Launch  Processing  System  (LPS),  is  designed  to  meet 
the  rapid  turn-around  requirements  for  a reusable  vehicle  and  to  reduce  the  number  of  people  involved 
in  vehicle  testing  and  launch.  At  the  same  time,  the  LPS  preserves  the  test  engineer's  direct  con- 
trol over  checkout  and  launch  procedures. 

The  LPS  is  a network  of  minicomputers  (up  to  64)  which  share  a common  data  buffer  to  pass  data 
and  commands  between  computers  and  the  vehicle.  Communications  between  the  LPS  in  the  LCC  and  the  ve- 
hicle is  accomplished  via  a Launch  Data  Bus  (LDB)  which  is  "attached”  to  the  GPCs  onboard. 

Two  key  differences  between  APOLLO  and  STS  have  been  realized  through  LPS:  visibility  through 

CRT  displays  (and  thus  digital  display  in  engineering  units  of  data)  of  status  and  data,  and  the  abil- 
ity to  perform  parallel  testing. 

Also  realized  through  LPS,  although  not  readily  "seeable"  to  the  user,  is  a high  degree  of  flexi- 
bility and  redundancy.  Since  the  LPS  is  a distributed  system,  any  minicomputer  can  be  loaded  from  a 
master  computer  with  a selected  subsystem  load.  Thus,  if  a console  and/or  a computer  fails,  a spare 
console/computer  can  be  quickly  brought  up  in  its  place.  Critical  system  functions  are  backed  up  in 
computers  in  such  a manner  that  a switch  can  be  made  with  minimum  loss  of  data. 

An  overview  of  the  LPS  and  its  architecture  is  presented  in  "The  Launch  Processing  System  for 
STS  and  DoD  Space  Shuttle"  by  Don  G.  Satterfield  (IBM),  published  in  the  IBM/FSD  magazine  Technical 
Directions,  Fall/Winter  1981,  Vol.  7,  Number  3. 


OBJECTIVES 

The  objectives  to  be  met  in  producing  the  ground/man-machine  interfaces  for  Orbiter  checkout 

were: 


* Rapid  turn-around  - Initial  requirements  for  an  operational  STS  called  for  a 160  hour  turn- 
around (10  working  days  of  two  shifts  each). 

* Minimization  of  "fixed"  software  - The  amount  of  software  residing  in  the  GPCs  uniquely  for 
checkout  was  to  be  minimized  as  well  as  minimizing  the  ground  software  which  was  "fixed",  that  is, 
tailored  for  a specific  vehicle/payload  configuration. 

* Flexible  capabilities  - Provide  engineers  with  "menu"  selection  of  predefined  tasks  to  be 
done  and  provide  the  capability  to  perform  contingency  tasks. 

* Complete  vehicle  checkout  - Provide  the  capability  to  test  the  Orbiter  in  the  Orbiter 
Processing  Facility  (OPF),  the  STS  (Orbiter,  ET,  and  SRBs)  in  the  VAB  and  at  the  pad,  and  the 
payload(s)  at  the  Cargo  Interface  Test  Equipment  (CITE),  OPF,  and  pad. 


IMPLEMENTATION 

The  objectives  spelled  out  have  been  met  through  implementation  of  computer  programs  in  onboard 
GPCs  in  PASS  and  in  the  LPS  computers,  and  procedures  for  engineers  to  use. 


Onboard  Capabilities 

The  primary  interface  between  the  LPS  and  the  vehicle  is  the  Launch  Data  Bus  (LDB).  While  a di- 
rect mode  between  LPS  and  the  command  decoders  onboard  exists,  we  are  primarily  concerned  here  with 
the  mode  where  the  LPS  and  the  GPCs  communicate.  In  this  mode,  polling  on  the  LDB  occurs  between  the 
LPS  and  the  GPCs  every  40  milliseconds,  with  an  established  protocol  being  followed. 
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Commands  from  the  LPS  may  be  directed  to  one  of  six  "functional  destinations"  in  the  GPC  and  may 
range  from  simply  setting  a discrete  on  in  an  MDM  to  initiating  a series  of  commands  to  an  actuator 
in  a predefined  pattern  up  to  100  times  a second  for  a Frequency  Response  Test  (FRT). 

Single  function  commands  are  sent  through  "operators"  in  either  the  Test  Control  Supervisor 
(TCS)  mode,  or  the  System  Avionics  Command  Support  (SACS)  mode,  based  on  availability  determined  from 
the  Operational  Sequence  the  GPC  is  in. 

Functions  such  as  the  FRT  reside  onboard  in  Explicitly  Coded  Programs  (ECPs)  which  are  designed 
to  accomplish  specific  tasks.  These  are  requested  from  the  LPS  via  a single  operator.  The  ECPs, 
once  requested  from  LPS,  will  execute,  based  on  parameters  from  LPS  contained  in  the  request,  without 
further  LPS  intervention. 

The  PASS  also  uses  the  LDB  to  communicate  with  the  LPS  in  the  final  phases  of  a launch  count- 
down. The  LPS  Ground  Launch  Sequencer  (GLS)  uses  the  LDB  to  send  control  commands  to  the  onboard 
Redundant  Set  Launch  Sequencer  (RSLS).  LPS  monitors  Launch  Commit  Criteria  (LCC)  on  the  ground  from 
the  STS  and  RSLS  to  determine  the  status  of  the  countdown. 

Another  key  element  of  vehicle  checkout  is  the  securing  of  data  from  the  various  subsystems  of 
STS.  This  is  accomplished  in  PASS  during  vehicle  checkout  by  the  Housekeeping  Data  Acquisition  (HDA) 
function  which  reads  the  various  avionics  related  hardware  and  provides  the  data  via  downlist  to  LPS. 
The  type  of  data  and  its  format  is  selectable  in  predefined  formats.  So,  unlike  APOLLO  with  its 
fixed  telemetry  stream,  STS  has  selectable  telemetry  streams  with  selectable  downlist  data  imbedded 
in  it. 

Finally,  the  PASS  has  several  autonomous  vehicle  checkout  capabilities  which  are  usable  from 
the  onboard  keyboard/CRT  system.  These  are  called  SPEC  (Specialist)  functions,  and  provide  for 
predefined  test  and  checkout  capabilities. 


Ground  Capabilities 

The  LPS,  as  discussed  earlier,  is  composed  of  a network  of  minicomputers.  Each  console/computer 
can  support  three  operators  who  may  be  doing  testing  of  different  aspects  within  their  subsystem  in 
parallel. 

In  addition  to  the  computers  at  each  console,  minicomputers  are  used  to  interface  to  the  LDB  and 
to  receive  data  from  the  STS.  These  computers  are  called  Front-End  Processors  (FEPs)  and  perform 
such  functions  as  preconditioning  data , formatting  requested  commands  properly  for  the  LDB,  switching 
data  formats,  etc. 

Engineers  produce  programs  for  the  console  computers  using  the  Ground  Operations  Aerospace  Lan- 
guage (GOAL),  written  by  IBM  for  use  in  LPS.  This  language  is  oriented  for  engineering  terminology 
and  provides  powerful,  yet  flexible  capabilities. 

In  addition  to  the  predefined  capabilities  generated  through  GOAL  programs  by  the  engineers,  LPS 
contains  a Command  Processing  system  whereby  an  engineer  can  "build"  commands  to  be  sent  to  STS  via 
the  LDB.  This  capability  allows  the  engineer  to  react  to  anomalous  conditions  and/or  to  accomplish 
a minor  task  which  would  not  warrant  generation  and  validation  of  a GOAL  program. 


ENHANCEMENTS 

In  large,  complex  computer  systems,  initial  designs  are  seldom  completely  adequate  or 
satisfactory.  The  STS  checkout  system  is  no  exception  to  this.  Many  enhancements  have  been 
suggested  and  are  either  already  implemented  or  planned. 

Drivers  for  these  enhancements,  for  the  most  part,  have  been  the  reduction  of  "special" 
considerations,  greater  flexibility,  and  increased  visibility.  For  example,  some  enhancements 
that  have  already  occurred  are: 

* The  selection  of  aerosurface  limits  for  movement  when  the  Orbiter  is  in  a horizontal  position 
in  the  OPF  or  a vertical  position  at  the  pad.  Initially  these  limits  had  to  be  "patched"  in  the  PASS 
to  change  them.  Now,  an  entry  on  a SPEC  function  display  allows  selection. 

* Increased  communication  of  TCS  status  between  PASS  and  LPS.  Additional  status  parameters 
have  been  added  to  ECPs  to  provide  the  LPS  better  visibility  into  reasons  for  rejection  or  failure  of 
ECPs. 


79 


* Selection  and  saving  of  IMU  parameters.  Similar  to  the  aerosurface  limits,  several  IMU  cali- 
bration parameters  change  when  the  Orbiter  is  in  different  locations.  Originally,  the  only  way  to 
change  these  was  via  a patch  to  PASS.  Now,  on  the  IMU  Calibration  SPEC,  the  vehicle  site  can  be 
selected  prior  to  calibration.  Also,  the  IMU  checkpoint  data  can  now  be  saved  on  all  areas  of  each 
Mass  Memory  Unit  (MMU)  directly  from  the  SPEC  function. 

The  enhancement  of  ground/man-machine  interface  is  not  complete.  Indeed,  a task  force  of 
engineers  from  the  Space  Shuttle  comnunity  still  meets  periodically  to  consider  suggested 
enhancements  which  will  make  the  system  faster,  more  reliable,  and  easier  to  use. 


SUMMARY 


The  STS  is  a very  complex  system  which  required  a quantum  step  forward  in  the  ground/man-machine 
interface  system  for  checkout.  This  step  has  been  made  with  the  combination  of  the  LPS  and  the  PASS, 
so  that  the  resulting  system  is: 

* Flexible 

* Powerful 

* Conducive  to  parallel  testing 

* Highly  visible 

* Conducive  to  multi-vehicle  flow  testing. 
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ABSTRACT 


This  paper  discusses  the  challenge  faced  in  the  development  of  an  integrated  ground  and 
on-board  system  for  Space  Shuttle  terminal  count  management.  The  criteria  considered  in  design- 
ing this  system  are  outlined  with  some  attention  given  to  examples  of  problems  encountered  in  the 
process  of  maturing  the  design. 


The  integrated  launch  system  developed  in  the  Space  Shuttle  program  requires  a closely  co- 
ordinated effort  between  the  ground  system  and  the  on-board  system.  The  system  had  to  be  struc- 
tured so  that  it  would  be  flexible  enough  for  more  rapid  reconfiguration  than  in  past  programs. 
This  was  true  not  only  for  ground  systems  but  also  for  the  vehicle  as  well.  This  is  a brief 
overview  of  the  development  of  the  Space  Shuttle  terminal  count  integrated  monitor  and  control 
system. 


The  Apollo  launch  support  systems  was  composed  of  two  computers,  one  located  in  the  mobile 
launcher  and  directly  locked  to  the  vehicle,  and  one  located  in  the  Launch  Control  Center.  These 
two  computers  were  connected  via  a data  link  which  provided  fixed  telemetry  streams  to  the  Launch 
Control  Center  for  vehicle  systems  evaluation.  The  majority  of  the  monitoring  function  was  done 
by  Firing  Room  personnel  looking  at  meters,  lights,  and  plotters  driven  by  the  Launch  Control 
Center  computer.  Thus,  the  Apollo  launch  approach  was  essentially  a fixed  system  which  was 
structured  to  provide  a single  sequential  flow  for  vehicle  checkout  and  launch. 

In  contrast  with  the  more  restrictive  approach  for  terminal  count  management  as  was  used  in 
Apollo,  the  challenge  arose  in  the  Shuttle  era  to  allow  a more  flexible  design  which  would  be 
adaptable  to  the  varied  configurations  of  the  launch  vehicle.  In  order  to  achieve  this  flexibil- 
ity a software  architecture  was  designed  for  both  on-board  and  ground  systems  to  readily  adapt  to 
any  requirement  changes.  This  approach  not  only  allowed  for  the  initial  development  of  the  inte- 
grated launch  system  but  also  supports  the  basic  concept  of  a multi-mission  Space  Shuttle 
Program. 


The  on-board  systems  management  software  structure  was  designed  based  on  individual  system 
inputs  as  to  command /moni tor ing  requirements.  The  terminal  count  and  launch  requirements  were 
considered  by  the  systems  during  the  definition  and  design  of  this  software  structure. 

The  ground  systems  software  structure  was  designed  to  meet  total  system  checkout  require- 
ments. These  include  the  requirements  for  terminal  count  capabilities. 


INTRODUCTION 


SOFTWARE  MANAGEMENT  IS  THE  KEY 


SOFTWARE  DESIGN  STRUCTURE 
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CONTROLLING  DOCUMENTS 


During  the  process  of  defining  these  t wo  software  systems  a interface  definition  document 
(CPDS-150)  was  developed.  The  primary  purpose  of  this  document  was  to  baseline  and  establish 
configuration  control  of  the  Launch  Data  Bus  (LDB)  interface  between  the  ground  and  on-board 
systems.  This  interface  definition  encompasses  both  day-to-day  test  and  checkout  requirements  as 
well  as  specific  terminal  count  requirements. 

Various  documents  exist  which  control  the  requirements  for  terminal  count  activities.  The 
on-board  software  requirements  (for  terminal  count)  were  specified  in  the  Functional  Subsystem 
Software  Requirements,  Sequencing  Requirements,  STS  81-0026  (FSSR-26).  The  Launch  Ccrrmit 
Criteria  (LCC),  JSC  16007  and  KSC  SOOOOO-3,  documents  were  established  and  are  maintained  by  JSC 
and  KSC.  The  Ground  Launch  Sequencer  Description  Document  (GLSDD-OMI-S9005)  establishes  the 
parameter  monitoring  and  sequencing  requirements  for  ground  systems  and  vehicle  systems  activi- 
ties in  support  of  terminal  count  and  launch.  The  above  documents  not  only  relate  software 
design  requirements  but  also  contain  real-time  anomaly  guidelines  such  as  hold/scrub  situations. 


SEQUENCE  CONTROL 
VEHICLE  SOFTWARE 

The  flight  GN&C  software  load  supports  all  of  the  vehicle  terminal  count  requirements. 
These  requirements  include  both  the  on-board  sequencing  as  well  as  the  system  software  necessary 
to  support  ground  initiated  tasks.  The  on-board  sequencing  software  has  interfaces  through  the 
GN&C  systems  software  with  both  the  Backup  Flight  System  (BFS)  computer  and  the  Space  Shuttle 
Main  Engine  (SSME)  computers.  Through  the  use  of  these  three  software  sets  all  Shuttle  systems 
are  managed/nronitored  for  terminal  count. 


GROUND  SOFTWARE 

The  Launch  Processing  System  (LPS)  application  software  supports  all  the  terminal  count 
requirements  for  ground  systems  and  vehicle  interfaces.  Most  of  the  terminal  count  activities 
are  incorporated  in  the  Ground  Launch  Sequencer  (GLS)  application  software.  The  remaining  termi- 
nal count  activites  are  con trolled /monitored  by  systems  engineers  via  their  own  application 
software.  The  vehicle  interface  for  these  activities  is  supported  by  the  cn-board  GN&C  system 
software  via  the  LDB  and  the  PCM  system.  This  interface  provides  the  LPS  access  necessary  to 
control  all  vehicle  systems. 


LIMITATIONS 


It  is  now  appropriate  that  a few  software  design  limitations  be  discussed  in  order  that  the 
reader  fully  appreciates  how  the  challenge  of  interfacing  the  ground  to  on-board  systems  with  the 
required  flexibility  was  achieved.  Trade-offs  of  total  software  design  capabilities  were  con- 
sidered which  resulted  in  today’s  limitations. 

One  of  the  primary  limitations  was  that  encountered  with  LDB  structure.  Design  considera- 
tions were  vehicle  weight  and  hardware  design  flexibility  in  choosing  a serial  interface  over 
parallel  interfaces  for  the  LDB.  Additionally,  software  complexity  and  memory  allocation  were 
drivers  in  the  decision  process.  The  resulting  LDB  structure  allows  240  msec  to  complete  one 
ground  to  on-board  transaction.  This  transaction  may  consist  of  a one-to-one  task  such  as  an 
operate  valve  request,  a predetermined  and  stored  sequence  of  one-to-one  tasks,  or  a special 
coded  flight  software  request  for  use  in  terminal  count.  A 120  msec  timing  may  be  achieved  by 
the  ground  requesting  to  inhibit  the  on-board  response  available  in  the  protocol.  The  serial 
data  operation  was  designed  with  a redundant  capability.  This  redundancy /design  includes  the 
necessary  data  bus  hardware  as  well  as  the  ground  and  on-board  software. 

Another  limitation  which  affected  the  terminal  count  protocol  was  the  design  of  ground 
software.  Each  firing  room  console  (terminal  count  activities  are  controlled  at  the  integration 
console  in  the  firing  room)  has  the  capability  of  running  six  application  tasks  in  addition  to 
several  other  system  software  tasks.  There  are  time  critical  functions  in  terminal  count  opera- 
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tions  which  require  stringent  control  of  these  six  application  tasks  in  order  to  avert  a console 
throughput  (timing)  problem.  Increased  console  throughput  activities  result  in  delayed  and 
inconsistent  LDB  operations. 

Limitations  for  vehicle  systems  management  arose  as  a result  of  constraining  the  number  of 
systems  parameters  to  be  processed  and  monitored  on-board.  This  limitation  is  taken  care  of  by 
the  ground  system  monitoring  and  processing  of  additional  parameters. 

The  combination  of  the  above  limitations  and  several  other  factors  led  to  the  biggest  chal- 
lenge which  was  managing  terminal  count  time  critical  events  and  time  critical  operations. 


DESIGN  CRITERIA 

The  design  criteria  of  coordinating  vehicle/ground  clocks,  performing  retries  of  parameter 
statusing  and  command  executions,  real  time  data  manipulations,  and  managing  potential  recycle/ 
scrub  activities  greatly  affected  the  integrated  terminal  count  software  structure. 


TIME  MANAGEMEM* 

Of  prime  importance  in  the  integration  of  terminal  count  activities  is  the  management  and 
control  of  the  ground  and  vehicle  clocks.  Greenwich  Mean  Time  (GMT)  is  the  reference  used  by 
both  the  ground  and  on-board  software  systems.  By  use  of  this  reference  the  countdown  clock  is 
initialized  and  controlled  by  ground  system  commands.  Countdown  time  is  used  to  initiate  all  of 
the  terminal  oount  events  required  by  the  vehicle  and  ground.  The  primary  challenge  in  this 
areas  was  the  detailed  analysis  and  coordination  required  to  place  each  function  at  a specified 
time  with  relation  to  its  associated  terminal  count  events.  An  example  of  the  need  for  integrat- 
ed timing  requirements  was  the  disposition  of  the  delta  that  existed  between  the  ground  and 
on-board  time  due  to  the  on-board  software  delaying  for  main  engine /vehicle  structure  stabiliza- 
tion prior  to  the  Solid  Rocket  Booster  (SRB)  ignition.  This  integrated  effort  was  required  to 
achieve  a common  T-0  lift-off  reference. 


RETRIES 

The  initial  design  requirement  was  to  provide  retry  logic  for  anomalous  conditions  prior  to 
initiating  corrective  action  or  proceeding  to  the  next  countdown  task.  Due  to  previously  men- 
tioned LDB  timing  constraints  in  conjunction  with  the  requirement  for  nominal  terminal  count 
tasks,  the  retry  logic  was  found  inappropriate  and  unachievable  in  most  cases.  Software  verifi- 
cation and  validation  testing  gave  the  confidence  required  to  assure  that  retry  logic  was  not 
mandatory  for  reasons  of  safety  or  for  the  high  probability  of  an  unsuccessful  software/hardware 
transaction.  The  data  transmission  "glitch"  problems  experienced  during  the  Apollo  era  which 
originally  drove  the  retry  design  requirement  were  found  to  be  non-existent  with  the  Shuttle 
hardware.  The  vehicle  application  software  was  structured  to  provide  retry  capability  for 
certain  tasks  based  upon  a systems  analysis  of  potential  problems  which  could  be  encountered. 
Even  though  the  ground  application  software  utilizes  minimum  retry  logic,  provisions  do  exist  in 
the  ground  systems  software  to  retry  unsuccessful  INPOT/OUTPtTT  transactions  three  times. 


REAL-TIME  OPERATIONS 

The  capability  of  manipulating  all  terminal  count  events  to  react  to  real  time  event  and 
parameter  deviations  was  another  requirement  consideration  in  software  design.  In  keeping  with 
this  requirement,  the  software  was  designed  to  allow  the  bypassing  of  any  terminal  count  task  and 
to  change  the  limits  of  any  terminal  oount  analog  measurement.  Provisions  were  made  in  the 
vehicle  software  for  bypassing  of  certain  vehicle  mon i tor/corrmand  tasks  in  response  to  ground 
system  inputs. 
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RECYCLE/SCRUB 


Another  criteria  which  influenced  the  integrated  software  design  was  capability  to  perform  a 
recycle  or  scrub  operation  at  any  time  during  the  terminal  count.  Vehicle  safing  requirements 
and  ground/vehicle  clock  synchronization  requirements  were  the  primary  drivers  in  implementing 
the  recycle/scrub  requirement.  Consideration  for  the  implementation  must  allow  for  a continually 
changing  vehicle  configuration  and  the  need  for  both  ground  and  vehicle  software  applications  to 
track  the  current  status.  In  the  design  of  the  recycle/scrub  software  logic  an  analysis  of  the 
independent  on-board  software  to  vehicle  systems  interface  and  ground  systems  management  proce- 
dures was  performed  to  assure  that  the  vehicle  could  be  placed  in  a safe  configuration.  For 
example  the  vehicle  application  software  was  programmed  to  go  through  its  predetermined  set  of 
recycle/scrub  safing  commands  and  then  terminate  all  activity  to  assure  no  interference  with  the 
ground  systems  tasks.  The  ground  systems  primarily  manage  the  reconfiguration  of  the  vehicle 
based  on  the  countdown  time  at  which  a recycle/scrub  was  requested. 


VERIFICATION  AND  VALIDATION 


As  previously  mentioned,  the  primary  integration  effort  required  of  the  ground  /vehicle  for 
terminal  count  operations  was  the  detailed  timing  analyses  to  verify  time  critical  operations. 
In  addition  to  the  individual  development  center's  analysis  and  verification  processes,  a highly 
integrated  test  activity  was  implemented  at  the  Lyndon  B.  Johnson  Space  Center  (JSC)  Shuttle 
Avionics  Integration  Laboratory  (SAIL)  and  at  the  John  F.  Kennedy  Space  Center  (KSC)  during 
actual  integrated  vehicle  functional  testing.  Hie  results  of  this  testing  were  fed  back  into  the 
ground  and  vehicle  software  design  requirements.  Software  changes  were  made  after  analysis  and 
trade-off  studies  were  performed  to  determine  whether  adjustments  could  best  be  made  on  the 
ground  or  on  the  vehicle.  Software  change  lead  time  constraints  played  an  important  part  in  this 
decision  process.  Numerous  changes  were  implemented  due  to  the  timing  analysis  and  testing 
results.  Adjustments  to  Launch  Commit  Criteria  also  caused  numerous  changes.  Any  change  always 
required  additional  analysis  and  a test  program  to  insure  that  no  unforeseen  problems  were 
created  or  compounded. 


EXAMPLE  PROBLEMS  ENCOUNTERED 


It  would  be  appropriate  at  this  point  to  discuss  several  situations  which  were  confronted 
during  the  process  of  integrating  the  terminal  count. 


SRB  LOCKOUT  MANAGEMENT 

At  a specific  point  in  the  countdown  sequence,  T-40  seconds,  the  SRB  Multiplexer- 
Demultipier's  (MDM's)  LL1/LR1  moules  0 and  4 are  commanded  to  the  lockout  state  in  preparation 
for  lift-off.  At  T-13  this  same  lockout  function  is  performed  for  LL2/LR2.  Initially,  in  order 
to  achieve  this,  the  ground  system  was  required  to  issue  20  LDB  one-to-one  transactions.  These 
commands  required  an  unacceptable  amount  of  time  to  accomplish  at  this  point  in  terminal  count. 
This  situation  was  analyzed  by  JSC  and  KSC  and  the  best  practical  solution  was  found  to  be  a 
change  to  flight  software.  It  provided  an  explicitly  coded  software  function  which  would  issue 
the  necessary  commands  to  accomplish  the  lockout  of  LLl/LRl  or  LL2/LR2  based  upon  a single  LDB 
transaction.  This  transaction  provided  a positive  response  to  the  ground  system  to  assure  each 
module  was  locked.  The  following  is  the  list  of  commands  for  LLl/LRl  that  was  initially  perform- 
ed from  the  ground  via  one-to-one  transactions  which  required  approximately  2.5  seconds  for  each 
set  of  MDM's. 

- READ  LL1  MDM  BITE 

- ISSUE  LOCK  LH  SRB  MDM  LU  MOD  0 

- READ  LL1  MDM  BITE 

IF  BITE  / 100016  EXIT  SEQUENCE  AND  SET  RESPONSE  TO  VERIFY  FAIL 

- ISSUE  LOCK  LH  SRB  MDM  LL1  MOD  4 

- READ  LL1  MDM  BITE 

IF  BITE  / 100016  EXIT  SEQUENCE  AND  SET  RESPONSE  TO  VERIFY  FAIL 
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- READ  LRl  MDM  BITE 

- ISSUE  LOCK  RH  SRB  MEM  LRl  MOD  0 

- READ  LRl  MDM  BITE 

IF  BITE  / 100016  EXIT  SEQUENCE  AND  SET  RESPONSE  TO  VERIFY  FAIL 

- ISSUE  LOCK  RH  SRB  MDM  LRl  MOD  4 

- READ  LRl  MDM  BITE 

IF  BITE  / 100016  EXIT  SEQUENCE  AND  SET  RESPONSE  TO  VERIFY  FAIL 

EXIT  SEQUENCE  AND  SET  RESPONSE  TO  VERIFY 

The  set  of  commands  to  perform  the  LL2/LR2  lockout  would  be  identical  to  the  above  with  the 
I .LI 's  replaced  by  LL2's  and  LRl's  replaced  by  LR2's.  The  flight  software  change  reduced  the 
ground  system  commands  to  one  LDB  transaction  for  each  set  of  MLM  lockouts. 

It  was  also  determined  that  in  the  case  of  a recycle/scrub  in  which  the  MDM's  had  been 
locked,  the  ground  systems  was  unable  to  reliably  time  the  unlock  sequence  using  one- for -one 
commands  (700  + 100  msec).  The  difficulty  was  due  to  the  unpredictability  of  LDB  traffic  and 
ground  software  activity.  It  was  determined  that  an  existing  "pulse  mode"  option,  available  in  a 
test  and  checkout  configuration,  would  best  provide  the  required  capability  in  the  prelaunch 
flight  configuration.  Flight  software  was  changed  to  provide  this  capability. 

With  this  integrated  effort  the  SRB  MDM's  may  be  locked  and  unlocked  in  a highly  efficient 
and  reliable  mode. 


SRB  HYDRAULIC  POWER  UNIT  (HPU)  START  & GIMBAL  PROFILE  MONITOR 

One  of  the  most  delicate  tasks  in  the  integrated  terminal  count  sequence  is  the  startup  and 
monitor  of  the  SRB  HPU's  which  occurs  inside  of  T-30  seconds.  Many  hours  of  design,  testing,  and 
data  analysis  were  used  to  insure  that  the  HPU's  could  be  started  in  a timely  manner  without  an 
overspeed  condition  and  that  the  SRB  gimbal  profile  which  immediately  follows  the  startup  seq- 
uence would  execute  properly. 

During  the  HPU  startup  sequence  one  GLS  design  requirement  had  to  be  waived  in  order  to 
allow  the  numerous  HPU  prestart  commands  to  be  issued  in  the  time  available.  The  requirement  was 
that  any  GLS  command  could  be  individually  bypassed  or  have  its  command  state  altered  during  a 
real  time  firing  room  environment.  For  the  HPU  prestart  sequence  it  was  decided  to  use  the  soft- 
ware capability  of  issuing  multiple  commands  via  a single  LDB  transaction. 

The  potential  inadvertant  runaway  overspeed  at  startup  is  monitored  by  the  use  of  an  LRS 
application  software  technique  known  as  Control  Logic.  Control  Logic  design  allcws  the  monitor- 
ing of  PCM  parameters  and  an  associated  predetermined  response  independent  of  the  actions  requir- 
ed of  the  normal  application  software.  The  turbine  speed  monitored  for  startup  is  higher  than 
the  normal  range  of  turbine  speed.  The  normal  GLS  application  software  monitors  the  normal  range 
of  the  HPU  turbine  speed  after  startup  has  occurred. 

In  the  process  of  vehicle  testing  flew  for  the  first  Space  Shuttle  launch  it  was  found  that 
the  enabling  of  this  normal  monitoring  function  was  about  100  msec  early  and  caused  a shutdown  of 
the  HPU  due  to  an  overspeed  condition.  This  anomoly,  which  was  caused  by  a controlled  higher 
initial  speed  in  the  start  as  requested  by  the  HPU  controller  was  not  considered  in  GLS  timing 
and  resulted  in  another  detailed  analyses  of  the  ground  to  vehicle  timing  for  terminal  count. 
The  GLS  enabling  of  overspeed  monitoring  was  subsequently  adjusted  to  correct  this  situation. 

At  T-21  seconds  the  SRB  Gimbal  profile  is  initiated  by  the  ground  software.  This  4 second 
test  of  establishing  a positive,  negative,  and  null  position  of  the  SRB  Tilt  and  Rock  actuators 
required  many  hours  of  testing  and  analysis.  Actual  vehicle  testing  along  with  the  SAIL  facility 
produced  the  necessary  data  to  provide  the  confidence  of  a good  system  checkout  and  a "go  for 
launch"  status. 


RECYCLE  AFTER  SSME  START  ENABLE  COMMAND 

An  example  of  an  integrated  task  which  included  the  SSME  controller  is  the  potential  main 
engine  shutdown  initiated  after  the  "start  enable"  command  has  been  issued.  Once  the  SSME  con- 
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troller  has  received  start  enable,  it  must  receive  the  "start"  command  within  5 seconds  or  "start 
enable"  must  be  commanded  again.  The  on-board  application  software  is  structured  such  that  once 
"start  enable"  is  commanded  the  only  command  that  may  be  sent  is  "start".  In  the  event  that  a 
recycle  occurs  after  "start  enable"  has  been  commanded,  the  time  out  between  the  two  commands  in 
the  SSME  controller  will  occur  but  the  on-board  count  cannot  be  resumed  without  a reload  of  the 
computer. 

The  decision  was  made  to  change  the  on-board  application  software  to  reinitialize  upon  re- 
cycle and  thus  allow  a resumption  of  the  count  without  reloading  the  cn-board  computer  program. 


STACKED  RESUME 

Whenever  the  on-board  application  software  is  requested  by  the  ground  or  detects  a limit 
violation  which  causes  it  to  go  into  a "hold",  the  ground  has  to  issue  a "resume"  count  request. 
In  the  initial  design,  the  on-board  system  software  would  accept  and  save  a "resume"  count 
request  sent  by  the  ground  even  though  a "hold"  was  not  in  effect.  Then,  when  the  next  hold 
condition  occurred  the  stored  "resume"  would  be  executed  immediately,  which  essentially  would 
negate  the  hold.  This  condition  was  discovered  in  testing  and  changes  to  both  on-board  and 
ground  software  now  precludes  the  possibility  of  the  on-board  inadvertantly  resuming  the  count. 


SUMMARY 

The  challenges  of  the  Integrated  Ground  and  On-board  Terminal  Count  development  may  be  sum- 
marized in  three  categories:  task  integration,  software  management,  timing  analysis.  Ihe  many 
functions  that  must  be  considered  and  implemented  into  a terminal  count  sequence  require  a super 
integrated  effort  among  many  contractors  and  many  disciplines.  The  incorporation  of  these  func- 
tions into  the  software  require  a well  managed  software  development  organization.  The 
verification/validation  that  all  functions  will  be  performed  in  an  efficient  and  timely  manner 
requires  a dedicated  test  team  approach. 

The  successful  launch  of  STS-1  and  subsequent  flights  is  proof  that  the  challenge  of  these 
three  important  functions  have  been  met  and  are  continuing  to  be  met  for  each  launch. 
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Orb iter/payload  avionics  integration  testing  is  a relatively  new  activity  in  the  shuttle  program. 
Payloads  flown  to  date  have  shown  extensive  orbiter  interfaces.  This  paper  describes  the  three  modes 
of  testing  at  Kennedy  Space  Center  and  Cape  Canaveral  Air  Force  Station  used  to  verify  orbi ter/payload 
avionics  interfaces.  These  modes  consist  of  orbiter  testing  using  generic  payload  simulators,  payload 
testing  utilizing  the  actual  payload  and  a high  fidelity  orbiter  simulator,  and  interface  testing  with 
the  actual  orbiter  and  payload.  Several  special  avionics  techniques,  such  as  the  split  flight 
computer  technique  have  been  developed  to  accomplish  this  testing.  Experience  from  the  first  six 
shuttle  cargoes  is  reviewed  with  emphasis  on  problems  found  in  testing  that  would  have  hampered 
mission  success. 


Opinions  expressed  by  the  authors  are  their  own  and  not  to  be  considered  as  official  expression  of  the 
Department  of  the  USAF  or  the  National  Aeronautics  and  Space  Administration. 
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INTEGRATED  DESIGN  CHECKOUT  OF  SHUTTLE  PAYLOAD  AVIONICS  INTERFACES 


Many  of  the  challenges  that  the  Space  Shuttle  Program  generated  in  integrated  avionics  have  been 
met  and  conquered  by  a variety  of  sophisticated  techniques.  In  this  session  we  have  seen 
presentations  of  the  tremendous  challenges  associated  with  flight  computer,  ground  computer,  and 
simulator  hardware  and  software  development.  The  challenges  which  we  are  going  to  discuss  in  this 
presentation  are  very  different  from  these  previous  areas.  The  challenges  of  these  other  areas  have 
been  substantially  met  and  resolved.  In  the  area  of  checkout  of  shuttle  payload  avionics,  however,  we 
are  just  beginning  to  understand  the  true  nature  of  the  challenge.  In  this  presentation  we  will 
discuss  our  approaches  at  Kennedy  Space  Center  (KSC)  and  Cape  Canaveral  Air  Force  Station  (CCAFS)  to 
perform  checkout  of  the  avionics  interfaces  between  the  orbiter  and  payloads.  This  presentation  will 
not  discuss  classified  defense  payload  processing.  We  will,  however,  discuss  integration  of  the 
Inertial  Upper  Stage  (IUS)  with  NASA  payloads  such  as  the  Tracking  and  Data  Relay  Satellite  (TDRS) • 
Also,  the  discussion  of  Spacelab  processing  will  be  limited  because  we  have  not  yet  completed  Spaceiab 
processing. 

The  primary  challenge  that  we  face  is  how  to  test  shuttle  and  payload  avionics  so  that  we  have 
confidence  that  when  the  payload  arrives  on  orbit  it  will  successfully  function.  These  interfaces  are 
definitely  substantial.  Table  1 shows  a list  of  payloads  carried  to  date  on-board  shuttle  missions. 
Several  observations  can  be  made  from  this  table.  First,  even  "simple”  payloads  like  the  OSTA  and 
OSS-1  pallets  carried  on  STS-2  and  STS-3  have  significant  avionics  interfaces.  Second,  the  amount  of 
interfaces  between  the  orbiter  and  the  payloads  are  growing  as  we  fly  more  sophisticated  payloads. 
This  trend  will  probably  continue  for  seme  time.  The  Centaur,  for  example,  will  have  more  extensive 
avionics  interfaces  than  the  IUS.  Therefore,  we  have  a significant  challenge  which  is  growing. 

There  are  many  factors  which  complicate  this  problem.  Some  of  these  are  very  unique  to  payload 
integration.  For  example,  for  many  of  these  payloads,  the  first  time  the  payload  avionics  is  actually 
connected  to  orbiter  avionics  may  be  as  late  as  2 weeks  before  launch.  A major  part  of  the  challenge 
of  interface  checkout  has  been  to  define  testing  to  detect  problems  in  the  interfaces  as  early  as 
possible.  Another  unique  complicating  factor  is  that  in  many  cases  we  are  dealing  with  organizations 
outside  of  the  Shuttle  Program.  In  some  cases,  the  users  have  been  extensively  involved  with  the 
shuttle  prior  to  arriving  at  the  launch  base;  in  others,  they  have  not.  In  almost  all  cases,  the 
payload  users  are  used  to  flying  expendable  boosters  where  the  interfaces  between  satellite  and  booster 
are  very  limited  (e.g.,  separation  indicators).  The  large  involvement  of  shuttle  hardware  in  payload 
mission  success  (providing  power,  telemetry,  attitude  control,  pointing,  commands,  etc.)  is  a new 
phenomena  to  most  users.  Another  major  carpi icating  factor  is  that  the  complex  payload  support 
services  provided  by  shuttle  are  just  beginning  to  mature.  The  S-Band  Payload  Communications  System, 
for  example,  did  not  arrive  at  KSC  much  before  its  first  use  by  a payload.  This  lack  of  experience 
with  this  hardware  at  the  launch  base  has  carpi icated  interface  verification  between  cargoes  and  the 
orbiter. 

In  order  to  meet  the  challenge  of  checkout  of  orbiter  payload  avionics  interfaces,  a system  has 
evolved  which  is  based  on  three  modes  of  interface  checkout.  This  system  is  still  evolving  and  is  very 
fluid  depending  on  a specific  payload  user's  needs.  In  general,  these  three  modes  ares 

MODE  A - CHECKOUT  OF  ORBITER  SUPPLIED  SERVICES  UTILIZING  ACTUAL  ORBITER  AND 
GENERIC  PAYLOAD  SIMULATORS 

MODE  B - CHECKOUT  OF  THE  PAYLOAD  TO  ORBITER  INTERFACES  USING  THE  ACTUAL 
PAYLOAD  AND  A HIGH  FIDELITY  ORBITER  SIMULATOR 
(CARGO  INTEGRATION  TEST  EQUIPMENT  (CITE))  AT  KSC 

MODE  C - INTERFACE  TESTING  UTILIZING  ACTUAL  PAYLOAD  AND  ORBITER 

This  mode  of  terminology  should  not  be  confused  with  the  "levels  of  integration"  used  by  NASA  Cargo  at 
KSC.  In  using  this  "mode"  terminology  we  hope  to  show  hew  a cargo  processing  through  the  shuttle 
launch  site  really  consists  of  three  distinct  phases  with  different  techniques  and  objectives.  This 
mode  terminology  will  not  be  found  in  any  formal  documentation  and  is  intended  for  clarity  in  this 
paper. 

The  main  purpose  of  Mode  A is  to  verify  that  the  orbiter  is  properly  configured  for  a given 
payload  and  that  all  of  the  orbiter  support  services  are  functioning. 
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Mode  B verifies  the  functioning  of  the  major  avionics  interfaces  between  the  actual  payload  and  an 
Orbiter  Simulator  (CITE).  In  addition  to  interface  verification,  several  other  types  of  testing  are 
performed  in  Mode  B.  Most  payloads  contain  ordnance  devices  such  as  separation  pyrotechnics  which  are 
tested  in  this  mode. 

Most  payloads  have  on-orbit  control  centers.  For  detached  payloads  these  control  centers  are  usually 
not  at  Shuttle  Mission  Control  at  JSC.  For  example  during  STS-6,  the  Tracking  and  Data  Relay  Satellite 
(TDRS)  was  controlled  by  a control  center  at  White  Sands,  New  Mexico.  In  order  to  verify  these  control 
centers  interfaces  to  the  payload,  an  "end  to  end"  test  is  usually  part  of  Mode  B.  In  this  test 
payload  telemetry  is  sent  to  the  control  centers  and  commands  are  sent  from  the  control  centers  to  the 
payload . 

The  other  major  test  that  is  performed  in  Mode  B is  Mission  Sequence.  Most  payloads  have  extensive 
mission  sequencing  of  events  that  involve  the  interfaces  between  the  orbiter  and  the  payload.  A good 
example  of  this  is  the  deploy  sequencing  of  PAM  Payloads  or  IUS  Payloads.  In  most  cases,  it  is 
impossible  to  test  the  interfaces  involved  in  this  sequencing  after  the  payload  has  been  installed  in 
the  orbiter.  This  is  usually  due  to  installation  of  ordnance  or  lack  of  access  to  test  points.  In 
order  to  test  these  interfaces,  a Mission  Simulation  is  run  which  includes  launch  countdown,  on-orbit 
checkout,  deploy  and  post  deployment  operations.  Items  that  are  included  in  this  testing  are  simulated 
ordnance  firing,  power  transfers,  and  umbilical  separations. 

Mode  C checkout  is  the  culmination  of  all  previous  testing.  Mode  C is  the  type  of  payload  to 
booster  interface  testing  that  has  traditionally  been  performed  at  the  launch  site,  i.e.,  post  mate 
testing.  Test  time  for  cargo  after  orbiter  mate  means  consuming  time  in  the  orbiter  schedule.  This 
time  is  expensive  in  terms  of  support  dollars  and  is  becoming  less  available  as  we  try  to  reduce 
turnaround  time.  Both  of  the  previous  modes  can  be  conducted  in  parallel  with  other  orbiter 
activities.  Mode  A testing  (orbiter  with  payload  simulator)  is  generally  a low  level  effort  and  can  be 
conducted  in  parallel  with  other  orbiter  servicing.  Mode  B testing  (payload  with  CITE)  does  not  affect 
the  orbiter  schedule.  By  conducting  these  two  previous  modes  we  greatly  decrease  the  risk  that  in  Mode 
C (post  cargo  mate)  testing  we  will  discover  major  problems  that  will  delay  launch  schedule.  This 
saves  real  dollars  in  terms  of  test  time  and  in  preventing  delays  to  the  shuttle  schedule. 

In  Mode  C testing,  the  major  objectives  are  functional  verification  of  interfaces  between  the 
cargo  and  the  orbiter,  "end  to  end"  testing  with  spacecraft  control  centers,  stray  voltage 
verification,  and  terminal  count  demonstration.  Many  of  these  tests  were  performed  in  Mode  B testing 
and  experience  from  this  testing  is  usually  very  applicable  to  Mode  C.  In  fact,  it  is  often  possible 
to  verify  solutions  to  problems  discovered  in  Mode  B during  Mode  C. 

Several  unique  techniques  have  been  developed  to  implement  these  three  modes  of  testing.  These 
techniques  are,  out  of  necessity,  very  fluid  and  are  constantly  changing  to  meet  individual  payload 
needs.  Some  of  the  more  common  techniques  are  described  in  following  paragraphs. 

MODE  A CHECKOUT 

Mode  A checkout  is  performed  in  the  Orbiter  Processing  Facility  (OPF).  Mode  A checkout  is 
performed  after  the  orbiter  has  been  configured  for  the  mission.  Configuring  the  orbiter  for  a 
specific  mission  usually  consists  of  the  following: 

Installing  Shuttle  Mixed  Cargo  Harnesses  (SMCH)  Cables  for  Specific  Cargoes 

Installing  Aft  Flight  Deck  (AFD)  Panels 

Installing  Payload  Retention  Fittings 

Configuring  Payload  Patch  Panel 

Installing  Interface  Electronics 

Loading  Orbiter  Flight  Software  with  Telemetry/De  com  Format  Loads 

Install  Remote  Manipulator  System  (RMS),  if  required 

In  Mode  A checkout  generic  payload  simulators  are  used  for  the  following  tasks: 

Sending  simulated  payload  telemetry  to  Payload  Signal  Processor,  (PSP)/ 

Payload  Data  Interleaver,  (PDI) /Payload  Interrogator,  (PI) /Payload 
Recorder/Communications  Interface  Unit  (CIU) 
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Sending  commands  via  orbiter  to  simulated  payload  using  PI/PSP/CIU/Multiplexer/Demultiplexer  (MDM) 

Verifying  Payload  timing  buffer  outputs  to  the  simulated  payload 

Verifying  Payload  power  voltage  and  current  at  Orbiter  connect  points 

Exercise  RMS  electrical  interface,  if  required 

These  generic  payload  simulators  are  basically  racks  of  electronics  capable  of  generating  simulated 
payload  telemetry  streams  and  receiving  payload  commands  and  timing.  They  are  programmable  to 
generate/accept  a wide  variety  of  data  types  and  rates.  They  are  not  designed  as  a specific  payload 
simulator  (e.g.,  a TDRS  simulator)  but  rather  are  designed  to  checkout  generic  capabilities.  These 
simulators  are  hooked  into  the  orbiter  at  the  same  places  that  the  payload  will  be  connected.  In  this 
way,  we  are  able  to  perform  "copper  path"  verification  of  the  mission  specific  cabling  used  to  support 
the  payload. 

In  addition  to  copper  path  testing,  functional  testing  of  orbiter  support  services  is  performed  in 
the  OPF.  For  example,  functioning  of  the  Payload  Recorder  is  performed.  Perhaps  the  most  extensive 
functional  testing  performed  is  with  the  S-Band  Payload  RF  System  and  the  Payload  Data  Interleaver. 

The  CPF  Communications  and  Tracking  (C&T)  Station  is  used  to  checkout  the  S-Band  Payload  System. 
Both  conmand  transmission  via  the  S-Band  Payload  System  and  telemetry  reception  are  checked  out  in  this 
manner. 

MODE  B PAYLOAD  TO  ORBITER  SIMULATOR  - CITE 

The  foremost  objective  of  testing  a payload  with  an  orbiter  simulator  like  CITE  is  to  minimize  the 
number  of  surprises  encountered  by  first  time  testing  and  mating  of  the  payload  and  orbiter.  To 
accomplish  this  objective,  the  Vertical  Processing  Facility,  the  Horizontal  Processing  Facility  and  the 
CITE  Control  Room  were  conceived.  The  major  initial  design  considerations  were  to  use  the  Orbiter  to 
Payload  interface  control  document  in  the  design  of  the  test  stands,  to  use  flight  type  avionics  for 
the  Pulse  Code  Modulation  Master  Unit  (PCMMU),  PDI,  MDM,  PSP,  PI  and  to  use  a smaller  Launch  Processing 
Unit  (LPS)  type  set  for  the  CITE  Control  Room.  These  design  considerations  allowed  procedures  and 
software  used  to  test  the  payload  to  be  validated  prior  to  orbiter  to  payload  testing. 

Since  the  original  CITE  did  not  have  a General  Purpose  Computer  (GPC) , LPS  was  designed  to  include 
a "GPC  Simulator”  in  CITE.  This  simulator  controlled  the  acquisition  of  downlist,  loading  of  the 
PCMMU,  PDI,  and  the  command  interface  to  the  payload  for  uplink  and  Launch  Data  Bus  (LDB)  commands.  It 
in  no  way  attempted  to  execute  the  GPC  flight  software.  This  design  was  more  than  adequate  for  OSTA, 
OSS  and  IUS  pathfinder  testing. 

For  OSTA  processing,  the  original  concept  of  processing  a payload  through  CITE  was  to  design  an 
automated  sequencer  in  the  LPS  which  would  be  patterned  after  the  mission  scenario.  This  concept 
proved  to  be  an  error  since  the  payload  requirements  and  the  mission  scenario  were  very  dynamic.  The 
LPS  software  could  not  be  modified  as  often  as  required  or  verified  and  validated  in  time  for  future 
payloads.  A decision  was  made  to  return  to  more  manual  programs  with  simple  d isplay/canrand  functions. 
Therefore,  the  Operation  and  Maintenance  Instructions  (OMI's)  would  control  the  testing  and  software 
redesign  would  not  be  necessary  if  the  mission  scenario  changed.  We  also  discovered  the  payload 
comnunity  and  the  flight  crew  wanted  to  use  the  GPC  flight  software  to  the  maximum  extent  possible. 

As  payloads  became  more  complicated  and  the  role  of  the  GPC  flight  software  become  more  involved 
with  the  payload,  it  became  apparent  that  a GPC,  Display  Electronics  Unit  (DEU)  and  Mass  Memory  Unit 
(MMU)  were  necessary  to  support  payload  testing  in  the  CITE  facility.  A CITE  Augmentation  System  was 
added  which  includes  the  GPC,  DEU,  MMU  and  an  Eclipse  Computer.  The  Eclipse  computer  simulates  the  GNC 
computer  of  the  Orbiter  (e.g.,  state  vector  and  uplink  command  routing).  By  using  a GPC  in  CITE,  the 
CITE  procedures  could  be  transferred  for  use  on  the  Orbiter.  It  was  also  determined  that  if  flight 
software  required  modification  as  a result  of  CITE  test,  there  would  be  enough  time  between  CITE  test 
and  post  orbiter /mate  of  the  payload  to  incorporate  the  software  change. 

To  support  the  payload  for  CITE  test,  the  test  stand  is  configured  to  support  the  payload  in  much 
the  same  manner  as  in  preparing  the  Orbiter  in  Mode  A.  Concurrent  with  the  hardware  reconfiguration, 
the  LPS  Ground  Software  Development  is  performed.  To  validate  the  Ground  Software  and  Flight  Software 
compatibility,  a test  prior  to  payload  installation  is  performed  where  the  payload  telemetry  stream  is 
simulated  to  match  the  Command  and  Data  Annex.  This  is  the  first  time  all  the  software  products  are 
truly  merged. 
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The  major  tests  will  be  described  under  Mode  C discussion  since  they  are  common  to  both  CITE  and 
post  orbiter  mate  testing.  The  only  unique  payload  test  performed  in  CITE  is  the  Mission  Sequence 
Test.  The  purpose  of  this  test  is  to  perform  a nominal  mission  flow  using  the  flight  data  file  and  to 
the  maximum  extent  possible  exercise  the  GPC  flight  software.  If  no  flight  software  problems  are 
detected,  this  testing  is  not  performed  after  the  orbiter  and  payload  are  mated. 

MODE  C TESTING 

Mode  C testing  is  performed  after  cargo  installation  in  the  orbiter.  For  horizontally  installed 
payloads,  this  activity  is  performed  in  the  Orbiter  Processing  Facility  (OPF).  For  vertically 
installed  payloads,  this  activity  is  performed  on  the  pad.  This  may  be  as  late  as  two  weeks  before 
launch.  Mode  C testing  consists  primarily  of  functional  interface  testing,  "end  to  end"  testing  with 
spacecraft  control  center,  ordnance  stray  voltage  testing,  and  terminal  countdown  demonstration. 

After  cargo  installation  and  electrical  connection  to  the  orbiter,  the  first  major  activity  is 
cargo/orbiter  interface  test.  The  major  purpose  of  this  test  is  to  perform  a functional  test  of  the 
interfaces  between  the  orbiter  and  cargo.  The  cabling  which  connects  the  orbiter  equipment  to  the 
payload  and  the  orbiter  services  should  have  been  checked  out  in  Mode  A.  The  payload  side  of  these 
interfaces  should  have  been  tested  in  Mode  B.  In  Mode  C,  we  basically  perform  the  Mode  B interface 
testing  with  the  real  orbiter. 

We  face  a significant  challenge  in  this  area  because  most  of  the  orbiter  support  to  payloads  is 
only  available  in  on-orbit  Orbiter  flight  software  operational  sequences  (OPS).  In  seme  cases  to  test 
significant  interfaces,  the  payload  must  also  be  moded  to  on-orbit  flight  software  modes.  The 
challenge  we  face  is  that  the  orbiter/cargo  is  still  on  the  ground.  Things  that  the  orbiter/cargo  are 
programmed  to  do  on-orbit  may  not  work  on  the  ground  or  even  worse  may  be  hazardous  to  equipment  and 
personnel.  Consider  the  disastrous  impacts  if  the  orbiter  decided  to  fire  thrusters  to  correct  its 
attitude  or  the  upper  stage  decided  it  was  time  to  separate. 

In  order  to  avoid  this  problem,  we  have  developed  several  techniques.  The  central  technique  is 
called  the  split  computer.  Diagram  1.  Under  split  computer  technique,  two  orbiter  computers  are 
activated  with  different  OPS.  One  computer  is  loaded  with  standard  ground  checkout  software, 
designated  GNC9.  The  other  computer  is  loaded  with  on-orbit  System  Management  software,  designated 
SM2.  The  orbiter  flight  critical  buses,  which  connect  the  orbiter  computers  to  most  of  the  flight 
control  and  other  flight  critical  equipment,  are  assigned  to  the  GNC9  computer.  This  effectively  safes 
most  of  the  orbiter  because  the  GNC9  load  will  not  perform  autonomous  subsystem  corrmanding.  The 
orbiter  payload  buses  which  connect  the  orbiter  computers  to  the  payload  multiplexer^demultiplexer 
(MDM) , PAM  Sequence  Control  Assembly  (SCA),  PDI,  and  other  payload  equipment  are  assigned  to  the  SM2 
computer.  The  SM2  computer  is  thus  able  to  communicate  to  the  payload  utilizing  the  on-orbit  software. 

There  are  several  problems  associated  with  this  configuration.  First,  there  is  a significant 
amount  of  orbiter  equipment  attached  to  "payload"  MDMs.  Included  in  the  SM2  Computer  is  "special 
processes"  software.  Special  processes  software  consists  of  automated  routines  which  perform 
housekeeping  of  flight  systems.  For  example,  the  SM2  computer  monitors  temperatures  in  the  hydraulic 
system  and  activates  the  hydraulic  system  and  the  hydraulic  circulation  pumps  to  keep  the  hydraulic 
fluid  from  freezing.  These  are  definitely  things  which  could  cause  havoc  during  ground  test.  In  order 
to  prevent  this  functioning,  the  applicable  systems  are  safed  by  cockpit  switches. 

Another  problem  which  occurs  is  that  of  downlink  bandwidth.  With  normal  vehicle  control  data 
being  downlisted  by  the  GNC  computer,  payload  interface  data  being  downlisted  by  the  SM  computer  and 
Payload  data  being  interleaved  into  the  downlink  by  the  PDI,  we  have  several  data  sources  all  competing 
to  fill  the  128  kbit  downlink  bandwidth.  The  normal  on-orbit  downlink/downi ist  formats  cannot  be  used 
because  they  do  not  have  the  kind  of  data  required  for  ground  operations.  More  specifically,  most 
on-orbit  formats  have  a very  small  window  for  the  GNC  downlist.  The  prelaunch  checkout  (GNC9 ) load  has 
a large  downlist  (51.2  kbit)  of  data.  At  KSC,  we  like  to  monitor  this  data  continuously  because  these 
systems  are  hazardous  (e.g.,  hypergolic  systems).  The  large  prelaunch  checkout  downlist  cannot  fit 
into  the  small  on-orbit  window.  In  order  to  solve  this  problem,  we  have  designed  special  downlink 
formats  that  have  all  of  the  critical  downlink  information  but  still  have  room  for  SM  and  the  payload 
data.  This  is  done  mostly  by  decreasing  sample  rate  of  high  frequency  measurements  and  by  specifically 
planning  to  drop  certain  kinds  of  special  test  measurements  (e.g.,  range  safety)  in  parallel  with 
payload  work. 

The  final  challenge  in  developing  this  test  configuration  is  to  find  a way  to  command  both  the 
orbiter  and  the  payload.  Sane  of  the  payloads  have  their  own  dedicated  umbilicals  through  the  orbiter 
T-0  umbilical  (e.g.,  IUS/TDRS,  PAM).  This  eases  the  command  problems  somewhat.  Other  payloads  require 
use  of  the  launch  data  bus  (LDB)  for  command.  This  presents  us  with  a dilemma.  We  need  the  launch 
data  bus  to  control  the  orbiter  flight  critical  systems  as  well  as  the  payload.  Normally  at  KSC  we  try 
to  keep  the  two  launch  data  buses  assigned  to  only  one  computer  at  a time  to  prevent  confusion  in  the 
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ground  and  flight  systems.  During  STS-2  and  3 pallet  checkout,  we  tried  to  pass  the  LDB  between  the 
GNC9  computer  when  we  needed  to  command  orbiter  flight  critical  systems  and  the  SM2  computer  when  we 
needed  to  command  the  payload.  The  result  of  this  technique  was  a lot  of  confusion  in  the  control  room 
as  to  what  computer  was  being  sent  commands.  This  is  a bad  situation. 

To  solve  this  problem  for  later  flows,  it  was  decided  to  split  the  launch  data  buses.  One  data 
bus  is  assigned  to  the  GNC9  computer  and  the  other  to  the  SM2  computer.  This  presented  us  with  some 
confusion  in  our  ground  system  with  regard  to  how  to  route  commands.  Rather  than  implement  some 
routing  software,  it  was  decided  to  use  two  separate  LPS  sets  in  two  different  control  rooms.  Since 
the  normal  control  room  is  designated  Firing  Room-1,  the  payload  control  room  is  designated  Firing 
Rocm-X.  This  system  has  been  used  extensively  for  STS-5  and  STS-6  with  great  success. 

An  additional  fallout  of  this  configuration  is  that  the  orbiter  uplink  can  be  used  to  command  the 
payload  - either  by  RF  or  hardwire.  Destination  codes  of  uplink  messages  can  be  set  to  the  GNC  or  SM 
orbiter  computer.  The  GNC  machine  receives  the  uplink  messages  from  the  Network  Signal  Processor  (NSP) 
and  sends  the  messages  to  the  SM  machine  via  the  Inter-Computer  Communication  (ICC)  bus,  if  required. 
At  KSC,  we  normally  use  the  LDB  for  most  command  purposes  because  it  is  more  versatile  than  for  the 
uplink  for  most  ground  testing.  However,  because  the  Orbiter  community  tends  not  to  use  the  uplink  for 
ground  checkout,  the  payload  community  has  begun  to  use  it  more  and  more.  In  hindsight,  it  makes  more 
sense  to  use  the  uplink  for  payload  checkout  because  payloads  are  designed  to  work  on-orbit  and  there 
is  extensive  payload  support  in  the  orbiter  uplink  software.  We  still  use  the  LDB  for  payload  checkout 
but  there  is  a definite  trend  to  use  more  uplink  commands  by  the  payload  community. 

Stray  Voltage  Ordnance  Testing  simply  consists  of  a demonstration  that  the  orbiter  systems  do  not 
induce  voltages  on  cargo  ordnance  lines  and  vice  versa.  This  is  not  an  electromagnetic  compatibility 
(EMC)  test,  since  EMC  testing  is  usually  a design  type  test/analysis  activity.  We  have  performed  some 
minor  EMC  testing  in  the  Orbiter  (Example:  Wireless  headset  compatibility  in  crew  cabin  with  IUS 
communications  interface  unit,  CIU)  but  this  is  not  normal.  In  stray  voltage  testing,  we  configure  the 
orbiter  and  the  payload  into  prelaunch  and  on-orbit  conditions  and  perform  voltage  checks  on  ordnance 
lines.  This  usually  involves  activating  a considerable  amount  of  orbiter  and  payload  equipment  such  as 
RF  systems,  payload  bay  floodlights,  hydraulic  circulation  pumps,  etc. 

"End  to  end"  testing  is  also  performed  after  cargo  mate.  Initially  (STS-2)  this  test  was  combined 
with  Orbiter /Mission  Control  Center  Compatibility  Testing.  As  we  have  gained  more  experience  with  the 
orbiter,  the  degree  of  payload  to  payload  control  center  testing  has  increased,  however,  MMC  to  orbiter 
testing  has  decreased.  Thus,  the  payload  control  center  "end  to  end"  tests  have  been  separated  from 
the  Orbiter/MCC  testing. 

These  "end  to  end"  tests  have  become  extremely  complex  affairs.  Diagram  2 shows  the  control 
center  testing.  No  less  than  11  separate  centers  were  processing  data.  In  fact,  in  one  test  we 
shipped  data  from  the  IUS  to  Sunnyvale,  CA  (SCF)  to  Greenbelt,  MD  (GSFC)  to  Houston,  TX  (JSC)  and  then 
to  White  Sands,  NM  (TDRS  Control).  This  data  criscrossed  the  country  3 times. 

In  "end  to  end"  testing,  we  ship  data  from  the  payload  to  the  user  control  center.  The  user 
control  center  also  formats  commands  and  ships  them  to  the  payload.  This  is  a test  of  the  payload,  the 
data  network,  and  the  payload  control  centers. 

The  purpose  of  the  terminal  count  demonstration  test  is  to  perform  a dress  rehearsal  of  the 
countdown.  STS-6  was  the  first  time  the  payload  community  was  actively  involved  in  the  demonstration. 
This  is  because  the  IUS  is  very  active  in  the  terminal  count.  There  are  two  critical  command  actions 
which  must  take  place  in  the  last  9 minutes  before  launch.  AT  T-5min30sec,  the  IUS  Inertial  Navigation 
System  is  commanded  to  free  inertial  mode  (flight  mode).  This  must  be  complete  before  Orbiter  APU 
start  at  T-5min.  It  must  be  commanded  as  late  as  possible,  however,  because  due  to  software/hardware 
limitations,  the  IUS  navigation  system  has  a limit  of  time  on  the  ground  in  the  free  inertial  state. 
At  T-3min59sec,  the  IUS  is  switched  from  orbiter  power  to  Airborne  Support  Equipment  (ASE)  batteries. 
This  is  to  lower  electrical  power  demand  on  orbiter  main  C power  bus  during  ascent.  The  ASE  batteries 
have  a limited  ground  budget  so  it  is  important  to  go  on  these  batteries  as  late  as  possible. 

In  order  to  properly  integrate  countdown  activities  with  the  orbiter  and  to  train  both  the  shuttle 
and  payload  launch  teams,  the  payload  functions  were  included  into  the  STS-6  Terminal  Countdown 
Demonstration  Test.  During  this  test,  it  was  discovered  that  the  time  required  to  issue  the  IUS 
navigation  to  flight  mode  command  and  the  delay  until  it  was  verified  at  the  Checkout  Station  (COS)  was 
very  long.  In  fact,  it  was  so  long  that  the  operator  at  the  Checkout  Station  did  not  have  enough  time 
to  call  a hold  prior  to  APU  start.  One  of  the  most  highly  stressed  rules  at  KSC  is  "You  don't  start 
APU's  unless  you're  ready  to  go."  This  is  because  APU  fuel  is  a limiting  factor  during  any  hold.  Most 
important,  if  all  of  the  APU  fuel  ground  budget  is  used,  it  forces  a several  day  reservicing  and  launch 
slip.  Based  directly  on  the  Terminal  Countdown  Demonstration  Test  experience,  we  changed  IUS  ground 
software  and  procedures  so  that  the  IUS  navigation  command  was  moved  back  30  seconds.  This  way,  we 
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were  assured  that  the  IUS  navigation  mode  was  completed  at  T-5min30sec  instead  of  just  starting  at 
T-5min30sec.  This  was  a very  important  lesson  to  learn  and  it  is  possible  that  we  avoided  an 
inadvertent  payload  hold  on  the  STS- 6 launch. 

We  expect  that  the  STS-6  cargo  is  the  first  of  many  cargoes  to  have  terminal  count  involvement. 
Preliminary  Centaur  High  Energy  Upper  Stage  planning  indicates  the  Centaur  will  have  extensive  terminal 
count  involvement.  The  Terminal  Countdown  Demonstration  Test  will  probably  grow  to  be  a very  important 
payload/upper  stage  test  in  the  future. 

RESULTS 

Now  that  we  have  presented  a rather  elaborate  test  program,  the  obvious  question  is  "Is  it  worth 
it?"  Based  on  experience  so  far,  we  have  found  that  this  program  regularly  detects  problems  that  could 
cause  launch  or  mission  failures. 

One  of  the  major  areas  in  which  we  have  found  problems  in  is  flight  software.  In  STS-5,  6 and  7 
processing,  we  have  found  errors  in  the  Command  and  Data  Annex  and  the  Master  Measurement  Data  Bank 
( MMDB ) . Improper  command  or  telemetry/decom  formats  were  in  the  data  base.  This  could  have  caused  the 
wrong  commands  to  be  issued  from  MCCH/POCC  or  wrong  interpretations  of  downlink  telemetry,  in  STS-5 
and  6,  we  also  found  that  the  flight  software  was  improperly  annunciating  payload  faults  or  displaying 
data  improperly  on  the  on-board  CRT.  In  some  of  these  cases,  it  was  possible  to  make  fixes  to  flight 
software  before  flight.  In  other  cases,  we  were  able  to  brief  the  crew  to  ignore  certain  alarms. 

In  a similar  item,  we  discovered  a CIU  to  Orbiter  incompatibility  during  Mode  A testing.  The  CIU 
rejected  the  GNC  State  Vector  transfer  from  the  orbiter  the  first  time  it  was  enabled.  This  caused  the 
CIU  to  turn  on  a "GPC  error"  light  on  the  CIU  display  panel.  We  found  that  if  the  crew  simply  cleared 
the  first  time  alarm  (by  pushing  a clear  pushbutton)  that  it  caused  no  further  problems. 

During  STS-5  pad  testing  of  a PAM,  a Sequence  Control  Assembly  (SCA)  failed.  It  issued  several 
inadvertent  commands  to  the  PAM  and  satellite.  If  this  had  happened  in  flight  we  might  have  damaged 
flight  hardware.  The  unit  was  replaced  with  a redesigned  unit  to  preclude  the  failure  mode. 

During  the  terminal  countdown  test  for  STS-6,  we  found  an  incompatibility  between  Shuttle  launch 
procedures  and  the  IUS.  At  T-llmin, , the  payload  bay  purge  flow  rate  is  lowered  to  lower  the  delta 
pressure  across  the  quick  disconnect  on  the  T-0  umbilical.  This  is  in  preparation  for  "popping"  the 
umbilical  at  liftoff.  In  terminal  count  demonstration  test  we  found  that  the  lower  flew  rate  altered 
the  thermal  environment  of  the  IUS  Redundant  Inertial  Measurement  Unit  (RIMU).  This  alteration  was 
sufficient  to  cause  large  drift  in  the  calculated  azimuth  of  the  RIMU.  If  the  first  time  this  had 
happened  had  been  launch  countdown,  we  certainly  would  have  scrubbed  the  launch.  Having  observed  this 
in  countdown  demonstration  test,  we  were  able  to  research  and  explain  it  so  it  was  not  a concern  on 
launch  day. 

A similar  item  was  observed  regarding  the  Orbiter  to  IUS  timing  interface.  At  approximately 
T-lhour,  a final  update  of  the  on-board  Greenwich  Mean  Time  (GMT)  in  the  Orbiter  Master  Timing  Unit 
(MTU)  is  made.  During  Orbiter  to  Cargo  interface  testing  (Mode  C),  we  found  that  an  update  of  the  MIU 
caused  the  IUS  to  declare  a timing  fault  and  go  onto  its  own  internal  time.  The  IUS  reset  back  to 
orbiter  time  within  a second  of  the  update.  This,  however,  caused  a Launch  Commit  Criteria  failure  in 
the  IUS  ground  computer.  This  would  have  caused  significant  problems  on  launch  day  if  we  had  not  been 
expecting  it,  perhaps  even  a scrub. 

There  are  many  other  examples  of  problems  we  have  found  that  have  had  an  affect  on  mission 
success.  The  above  examples  are  "typical"  problems  we  find. 

SUMMARY 

We  have  described  the  three  modes  of  checkout  that  have  evolved  at  KSC  and  CCAFS  for  Payload  to 
Orbiter  Interface  Checkout.  Mode  A consists  of  copper  path  checks  of  mission  unique  wiring  and 
functional  checks  of  orbiter  supplied  payload  services  such  as  the  payload  recorder  and  the  S-Band 
Payload  system  on  the  orbiter.  Mode  B consists  of  checkout  with  the  real  payload  and  a high  fidelity 
orbiter  simulator.  Typical  testing  that  occurs  in  Mode  B is  CITE/Cargo  interface  test,  "end  to  end" 
test  with  control  centers,  ordnance  test  and  mission  sequence  test.  Mode  C testing  is  performed  after 
cargo  installation  in  the  orbiter.  This  is  similar  to  traditional  booster  to  spacecraft  integration 
testing,  but  much  more  extensive.  A full  Cargo/Orbiter  Interface  test,  and  "end  to  end"  test.  Ordnance 
test  and  a Terminal  Countdown  Demonstration  test  is  performed. 

These  testing  modes  have  found  numerous  problems  with  spacecraft  processed  at  KSC  and  CCAFS  to 
date.  This  system  will  continue  to  evolve  as  more  complex  payloads  arrive  at  the  launch  base  with 
increasingly  compressed  processing  schedules. 
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PAYLOAD/MI SSICN 

INTERFACE  SUMMARY 

STS-l/DFI  PALLET 
INTEGRATED  ENVIRONMENT 
CONTAMINATION  MONITOR  (IECM) 

PAYLOAD  MDM  COMMAND  INTERFACE 

STS-2/OFFICE  OF  SPACE  AND 
TERRESTRIAL  APPLICATIONS  (OSTA-1) 
PALLET 

FLEX  MDM  INTERFACE 

FLIGHT  SOFIVZARE/ ON-BOARD  CRT  DISPLAY 
ORBITER  POWER 

DATA  IN  GPC  DCWNLIST  (SM  GPC) /COMMAND  BY  S BAND  PM 

STS— 3/OFFICE  OF  SPACE  SCIENCE 
(OSS-1)  PALLET 

FLEX  MDM  INTERFACE 

FLIGHT  SOFTWARE/ON-BOARD  CRT  DISPLAY 

ORBITER  POWER 

DATA  IN  GPC  DCWNLIST  (SM  GPC)/COMMAND  BY  S BAND  PM 
PAYLOAD  TELEMETRY  BY  S BAND  FM 
RMS  PCWER/DATA  INTERFACE 

STS-4/DOD  82-1 

CLASSIFIED 

sts-5/telesat  anik  on  payload 

ASSIST  MODULE  (PAM)  AND  SATELLITE 
BUSINESS  SYTEM  (SBS)  ON  PAM 

SEQUENCE  CONTROL  ASSEMBLY  (SCA)  ON  PAYLOAD  DATA  BUS 
PAYLOAD  DATA  INTERLEAVER  (PDI) 

S BAND  PAYLOAD  SYSTEM  (SIGNAL  PROCESSOR/INTERROGATOR) 
ORBITER  POWER 

FLIGHT  SOETWARE/AUTOMATIC  SEQUENCING 
ON-BOARD  CRT  DISPLAY 

SUBSTANTIAL  FUNCTION  ON  STANDARD  SWITCH  PANEL  (SSP) 

STS-6/TRACKING  AND  DATA  RELAY 
SATELLITE  (TDRS-a (/INERTIAL 
UPPER  STAGE  (IUS-1) 

COMMUNICATIONS  INTERFACE  UNIT  (CIU)  TO  PAYLOAD  MDM 
ORBITER  STATE  VECTOR  TRANSFER  TO  PAYLOAD 
FLIGHT  SOFTWARE/ON-BQARD  CRT 
PAYLOAD  DATA  INTERLEAVER  (PDI) 

S BAND  PAYLOAD  SYSTEM  (SIGNAL  PROCESSOR/INTERROGATOR) 
ORBITER  POWER 

PCWER  CONTROL  PANEL  AND  STANDARD  SWITCH  PANEL 
TDRS  COMMAND  VIA  ORBITER  S BAND  PM 

ALL  PAYLOADS  HAD  PAYLOAD  RECORDER  AND  PAYLOAD  TIMING  BUFFER  INTERFACE 
TABLE  1 PAYLOAD  INTERFACE  SUMMARY 
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DIAGRAM  1 SPLIT  COMPUTER  TECHNIQUE 
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DIAGRAM  2 


STS-6  END  TO  END  TEST  (TDRS-A/IUS-1) 
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ABSTRACT 


The  Space  Shuttle  checkout  is  quite  different  from  its  Apollo  predecessor.  The  complexity 
of  the  hardware,  the  shortened  turnaround  time,  and  the  software  that  performs  ground  checkout 
have  proven  a challenging  task  to  overcome. 

Generating  new  techniques  and  standards  for  software  development  and  the  management  struc- 
ture to  control  it  have  been  implemented.  New  challenges  await  those  that  have  been  solved. 


INTRODUCTION 

Testing  of  the  Space  Shuttle's  many  systems  to  assure  that  the  Shuttle  is  ready  to  refly  is 
a complex  process.  This  paper  will  highlight  some  of  the  challenges  in  utilizing  these  oomputer 
systems  in  the  testing  of  the  vehicle  in  a timely  fashion  and  hew  these  challenges  are  being  met. 

HISTORY 

During  the  Apollo  program,  the  Saturn  launch  vehicle  was  heavily  oomputer  controlled  (via 
the  RCA  110 A computers)  and  had  virtually  no  oockpit  control  since  the  Apollo  spacecraft  was 
totally  separate.  The  ground  computer  programs  were  primarily  assembly  language,  with  very  low 
change  rate.  A very  elementary  user  test  language  (ATOLL)  was  available  for  "linking"  assembly 
language  programs  and  to  perform  simple  command  verification  sequences.  This  capability  allowed 
KSC  to  automate  the  last  nine  hours  of  countdown  to  an  almost  hands-off  point  by  the  end  of  the 
Apollo  program. 


Where  the  Saturn  automation  was  primarily  a oommand-by-command  serial  sequencing  function, 
the  automation  of  the  Shuttle  checkout  and  launch  preparation  is  a very  complex  scheduling 
exercise,  with  complex  operations  to  be  performed.  The  tools  provided  were:  1)  the  LPS  system, 

with  its  GOAL  user  oriented  language,  capable  of  monitoring  the  measurements  on  the  vehicle  and 
in  the  ground  systems,  and  (2)  the  on-board  computer  system  (DPS),  which  provided  the  linkage  to 
control,  in  a test  environment,  all  the  vehicle  subsystem  controllable  during  flight. 

CHALLENGES 

The  complexity  of  the  Space  Shuttle  has  come  to  haunt  us  frequently  in  our  efforts  to  auto- 
mate our  turnaround  activities  — from  the  sheer  numbers  of  measurements  to  be  non i bored  and 
commands  to  be  issued  to  the  interrelationships  of  the  subsystems.  The  flexibility  of  redundancy 
makes  a highly  reliable  vehicle  to  fly,  however,  a difficult  one  to  test.  Our  earliest  efforts 
at  automated  testing  were  just  to  get  the  minimum  amount  of  software  written  to  get  the  job  done 
— we  did  not  have  time  for  any  more.  As  we  progressed  thru  the  STS-1  flow,  the  need  to  <V> 
things  faster,  and  more  reliably  became  strong  drivers.  For  manual  operations,  we  found  all 
many  ways  one  could  do  them  — many  which  would  not  work! 

We  also  found  during  the  early  flows  that  we  were  spending  large  amounts  of  manpower  sitting 
in  the  firing  rocm  waiting  for  a problem  to  occur.  As  problems  decreased  teeause  of  system 
maturity,  we  still  needed  the  same  number  of  people  on  console  monitoring  data*  This  was  neither 
cost  effective  nor  interesting.  In  order  to  have  a cost  effective  system  we  to  reduce  Firing 

Rocm  manpower. 
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The  shortening  of  the  turnaround  has  been  a constant  driver  to  get  things  done  faster  and 
more  efficiently,  (Reference  Table  1).  The  STS-7  turnaround  was  63  days  and  our  target  for 
STS- 30  is  28  days,  a 60%  reduction.  This  can  be  attacked  several  ways  — decrease  test  require- 
ments, accomplish  the  same  tests  faster,  and  accomplish  more  testing  in  parallel. 


TABLE  I.  FLIGHT  vs.  TURNAROUND  FLOW  LENGTH 
FLIGHT  LENGTH 


STS-1 

2 years 

STS-7 

63  days 

STS-8 

49  days 

STS- 16 

35  days  (target) 

STS- 30 

28  days  (target) 

SOLUTIONS 


Our  first  approach  at  speeding  operations  up  was  to  automate  discrete  activities.  During 
early  STS-1  it  would  take  us  over  two  hours  to  power  up  the  Or  biter.  This  drove  us  to  a 24 
hour/day  operation  in  just  one  week  to  avoid  the  overhead  of  the  daily  power-up  time.  We  are 
currently  powering  up  OV102  (STS-9)  daily  in  less  than  25  minutes.  Curing  this  time  period, 
approximately  500  commands  are  issued  via  computer  and  approximately  50  switches  are  thrown  in 
the  cockpit.  How  did  we  do  it?  First,  each  of  the  institutional  support  systems  (EPDC,  instru- 
mentation, cooling  and  DPS)  developed  software  to  automatically  perform  each  of  their  power  up 
functions  with  a minimum  of  manual  intervention.  Control  of  these  programs  was  then  centralized 
at  the  integration  console  which  cues  each  of  the  subsystem  consoles  when  it  is  time  to  do  a part 
of  their  activation.  Procedural  steps  which  must  be  run  manually  are  tutor ially  presented  to  the 
console  operator.  This  eliminates  any  unnecessary  decision  making  in  selecting  the  proper 
support  LRU's  for  the  day  and  "filling  in  the  blanks".  It  also  allowed  all  measurement /feedback 
information  to  be  checked  by  the  software. 

Could  these  kinds  of  techniques  be  applied  to  other  situations?  Certainly,  however,  our 
normal  testing  situation  is  not  as  easily  predefinable  on  a day  to  day  basis  as  power  up.  Today 
we  may  want  to  test  system  A then  B then  C.  Tomorrow  we  may  need  to  test  A in  parallel  with  C 
and  then  do  B.  There  are  many  drivers  to  the  order  of  testing  — manpower  available  to  do  a job. 
Ground  Support  Equipment  ready,  compatibility  of  operations  (downlist/downlink  formats,  GPC 
memory  configuration,  etc.)  and  the  jobs  scheduled  due  to  unexpected  drivers  such  as  equipment 
failure  and  replacement. 

In  order  to  automate  on  a global  firing  room  basis,  we  first  have  to  automate  individual 
subsystem  functions.  This  is  currently  underway.  To  assure  that  these  functions  can  then  be 
integrated,  a common  set  of  groundrules  (standards)  have  been  developed  to  assure  that  subsystems 
can  communicate  with  one  another  and  with  the  integration  console  in  a uniform  manner. 


STANDARDS 

A set  of  groundrules  were  established  to  design  the  application  software.  Early  efforts 
concentrated  on  standardizing  the  man-computer  interface.  Standards  were  developed  for  the  use 
of  color  on  the  CRT's  and  on  hew  the  data  was  to  be  displayed.  Standards  were  developed  on  hew 
the  engineer  would  use  the  CCMS  keyboard  to  communicate  to  the  application  software.  Later  stan- 
dards were  developed  that  provided  rules  on  hew  the  software  structure  was  to  be  designed.  This 
standard  identified  program  types  and  the  relationship  of  each  type  to  the  overall  design  of  the 
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software  set.  Application  sets  were  defined  along  engineering  subsystems,  e.g.,  Hydraulics, 
Environmental  Control  and  Life  Support,  Electrical  Power  Distribution  and  Control,  Data 
Processing,  etc.  These  Application  Sets  were  assigned  to  a physical  Firing  Rocm  console  and 
teams  were  established  by  console  to  produce  the  documentation  and  software. 

Each  Console  Set  Working  Team  is  comprised  of  contractor  and  NASA  system  engineers  from  each 
member  Application  Set,  software  specialist  engineers,  technical  documentation,  and  quality 
control  personnel.  The  teams  are  responsible  for  producing  console  application  software 
requirements,  software  design  specifications,  and  development  and  implementation  of  the  software 
itself.  The  teams  meet  on  a regular  basis  to  coordinate  requirements  and  implementation 
details.  This  highly  orangized  activity  is  opposed  to  the  methods  used  earlier  where  a system 
engineer  had  a broad,  general  set  of  requirements  which  he  went  off  and  coded  to.  Since  most 
programs  were  simple,  stand-alone  programs,  this  method  was  satisfactory.  The  increased  level  of 
organization  and  coordination  was  driven  by  the  increased  complexity  and  interdependency  of  the 
software  which  was  required.  Because  this  software  was  now  going  to  be  used  at  multiple  sites 
(VAFB) , and  because  it  would  probably  be  with  the  Shuttle  program  longer  than  its  designer,  docu- 
mentation became  more  important. 

In  addition  to  the  console  set  working  teams,  someone  had  to  assure  the  consoles  would 
communicate  properly  with  one  another,  and  that  subsystems  required  to  support  other  subsystems 
were  aware  of  it.  This  function  is  provided  for  by  the  Software  Automation  Subpanel.  This 
group's  primary  responsibility  is  the  integration  of  the  automation  effort  within  the  Firing 
Room. 


STRUCTURE  STANDARD 

The  Software  Structure  Standard  establishes  a software  design  that  separates  the  overall 
software  function  into  primarily  three  groups.  Display  Driver  programs  are  the  primary  man- 
machine  interface.  The  operator  uses  these  Display  Driver  programs  to  initiate  software  func- 
tions and  also  to  view  data  on  the  engineering  system.  While  looking  at  an  overview  display  of  a 
Shuttle  system,  the  operator  may  move  a cursor  to  a target  on  the  CRT  which  causes  the  overview 
display  to  terminate  and  another  Display  Driver  is  to  be  performed  which  displays  a particular 
subsystem  in  greater  detail.  This  Display  Driver  may  have  cursor  targets  that,  when  selected, 
cause  a particular  command  to  be  issued.  The  command  feedback  is  displayed,  allowing  the  opera- 
tor visability  into  system  response  to  the  command. 

Sequencer  programs  are  designed  to  automate  a particular  function.  There  are  Sequencer 
programs  that  power-up  a particular  hardware  system  on  the  Orbiter.  There  are  sequencers  that 
perform  detailed  LRU  checkout.  In  general,  a sequencer  requires  no  manual  control  except  to 
perhaps  supply  program  options,  or  respond  to  errors.  A sequencer  provides  only  limited  operator 
interface  capability.  Instead  the  sequencer  interfaces  with  Display  Driver  programs  to  display 
messages  or  to  present  prompts  to  the  operator.  The  Sequencer  program  is  also  responsible  for 
recognizing  and  reacting  to  system  anomalies. 

The  third  class  of  programs  are  those  that  bind  the  other  program  types  together  and  provide 
the  continuity  between  one  function  and  another.  The  main  program  in  this  type  is  called  the 
System  Scheduler.  The  purpose  of  this  program  is  to  validate  all  requests  to  perform  a function 
against  functions  already  in  progress  and  the  current  hardware  configuration.  It  also  estab- 
lishes a relative  priority  among  functions  and  will  interrupt  one  task  to  execute  a task  of  a 
higher  priority.  The  System  Scheduler  is  the  hub  of  inter  and  intra  console  software 
communication.  When  one  program  needs  to  communicate  to  another  it  sends  the  request  to  the 
System  Scheduler  which  will  validate  the  request  and  relay  it  to  the  proper  receiving  program. 
This  same  scheme  works  when  one  Application  Set  needs  to  send  data  to  or  request  data  from 
another  Application  Set.  This  standardized  communication  scheme  provides  the  linkages  that  form 
an  integrated  Application  Set  and  ultimately  an  integrated  Firing  Room  software  design. 


CONSOLE  STATIONKEEPING 

In  order  to  solve  the  problem  of  decreasing  the  number  of  engineers  required  on  console 
during  relatively  quiet  periods  while  other  subsystems  are  testing,  we  developed  a concept  called 
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"Stationkeeping",  (frequently  referred  to  as  "babysitting").  Depending  upon  the  system  being 
station-kept,  the  level  of  monitoring  of  functions  and  automatic  response  varies.  All  systems 
have  a set  of  measurements  which  are  monitored  for  anomalous  conditions.  In  general,  these  meas- 
urements are  monitored  against  limits  in  the  Front  End  Processors.  When  a limit  is  violdated,  an 
interrupt  is  sent  to  the  GOAL  program  at  the  console.  In  response  to  this  interrupt,  the  program 
then  evaluates  a set  of  related  measurements  to  determine  what,  if  any,  the  failure  was.  A 
message  indicating  the  failure  is  then  sent  to  the  operator.  In  the  case  where  no  operator  is 
present,  the  message  is  routed  to  the  Integration  console  for  display  to  the  operator  there. 

What  happens  in  response  to  an  error?  Here  again,  this  is  system  dependent.  In  DPS,  any 
failures  which  degraded  the  testing  support  (such  as  a GPC  failure)  caused  data  collection  to  be 
automatically  initiated  and  a proposed  plan  for  recovery  to  be  displayed  to  the  operator.  If  the 
console  operator  selects  to  perform  the  recovery  plan,  all  steps  which  can  are  automatically 
executed.  Any  steps  requiring  manual  actions  are  presented  in  a tutorial  fashion.  This 
software,  in  essence,  is  a canned  "expert  system  engineer"  who  knows  what  to  do  ahead  of  time  in 
all  predictable  failures.  There  undoubtably  will  be  cases  which  the  software  was  not  designed  to 
cover.  When  these  occur  they  will  be  added  into  our  software,  thus  teaching  our  "expect"  some- 
thing new. 

The  concept  of  stopping  to  provide  the  console  operator  with  an  option  to  perform  the  re- 
covery sequence  or  not  is  not  used  in  all  cases.  In  many  instances,  because  of  possible  hazards 
involved  or  potential  hardware  damage,  recovery  is  invoked  automatically.  Loss  of  cooling  is  an 
example  where  steps  are  automatically  taken  to  restore  cooling  to  the  vehicle  without  operator 
intervention. 

Once  we  developed  the  concept  of  stationkeeping  software  for  systems  when  engineers  were  not 
going  to  be  on  station,  it  was  just  an  extension  to  also  use  this  same  software  when  the  engineer 
was  on  station.  This  helps  in  assuring  the  appropriate  data  is  taken  when  a problem  occurs  and 
that  the  correct  steps  are  taken  to  correct  a problem.  This  allows  less  experienced  engineers  to 
become  console  operators.  The  stationkeeping  concept  has  also  been  extended  to  systems  such  as 
hydraulics  to  provide  their  "incident  prevention"  software  which  causes  emergency  hydraulics 
power  down  whenever  anything  is  detected  which  indicates  the  system  is  incorrectly  configured  or 
something  critical  has  failed  which  could  result  in  hardware  damage. 

In  the  case  of  DPS,  in  order  to  have  Integration  console  do  their  stationkeeping  a number  of 
support  functions  had  to  be  performed  from  the  Integration  console  (i.e.,  format  changes,  launch 
data  bus  switching,  I/O  resets,  etc.).  This  was  easily  implemented  using  the  communication  tech- 
niques described  above.  As  the  system  matures,  additional  capabilites  will  be  added  to  the  Inte- 
gration console  menu  of  DPS  functions  to  increase  the  amount  of  time  stationkeeping  can  be  active 
from  the  Integration  console. 

Although  our  stationkeeping  software  is  still  under  development,  we  have  already  begun  to 
reap  the  rewards.  DPS  stationkeeping  software  went  on  station  during  STS-6.  Approximately  80% 
of  the  flow  is  now  done  with  no  one  at  the  DPS  console.  This  solves  many  problems: 

o More  cost  effective  utilization  of  manpower. 

o Improved  morale  by  decreasing  shift  work. 

o Allow  engineers  to  work  more  interesting  tasks. 


THE  CHALLENGE  IS  NOT  OVER 


The  solutions  that  have  been  outlined  have  a common  denominator.  They  all  require  highly 
integrated  and  complex  software.  Early  efforts  at  automation  isolated  top  level  functions  from 
one  another  to  minimize  the  amount  of  interaction  between  software  elements.  This  methodology 
worked  fine  but  it  would  not  support  an  environment  where  multiple  semi-independent  operations 
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Firing  Roan  environment  is  exactly  what  is  needed  to  produce  a turnaround  concept  that  minimizes 
human  intervention  and  decision  making.  New  that  we  have  solutions  for  our  past  challenges,  new 
ones  confront  us  in  our  efforts  to  control  this  huge  ball  that  has  begun  to  roll  called  "automa- 
tion". The  software  development  tools  that  we  have  used  in  the  past  were  fashioned  after  our 
level  of  sophisticated  software  which  in  most  cases  was  crude.  The  new  challenge  that  we  face  is 
to  produce  the  software  development  tools  and  techniques  that  will  keep  the  automating  ball  roll- 
ing in  the  right  direction  and  speed  so  as  not  to  swallow  up  those  of  us  in  its  path. 

For  the  most  part,  mathematical  models  of  the  various  Shuttle  and  ground  support  systems 
were  used  to  verify  the  checkout  application  software.  Our  simulation  capability  is  called  the 
SQOS  (Shuttle  Ground  Operations  Simulator)  system.  It  consists  of  math  models  executing  under  a 
real-time  operating  system  in  one  of  our  ground  data  processing  computers  and  another  computer 
that  supports  the  Orbiter  and  ground  data  links,  buffering,  and  data  conditioning  between  the 
Firing  Roam  and  the  real-time  operating  system.  To  the  Firing  Room  personnel  and  their  software 
executing  in  the  consoles,  a high  fidelity  math  model  will  provide  measurements  and  react  to 
commands  identically  to  its  hardware  counterpart.  The  math  models  would  adequately  allow  the 
engineer  to  debug  and  verify  his  mostly  manually  controlled  programs,  but  they  were  not  to  the 
level  of  fidelity  to  simulate  a total  system  response  to  a stimuli.  The  need  to  have  high  fidel- 
ity integrated  models  of  hardware  was  an  obvious  priority  when  we  began  our  automation  effort. 
Once  high  fidelity  models  were  produced,  we  quickly  ran  into  the  limits  of  the  real-time  simula- 
tion capabilities.  Unlike  other  NASA  centers,  we  don't  have  dedicated  computers  for  our  math 
models  to  run  in.  Instead  we  designed  a real-time  simulation  operating  system  that  would  time- 
share  the  computer  resources  with  many  other  operations.  Because  of  this  constraint,  the  problem 
of  increasing  the  simulation  capability  without  taking  over  the  whole  computer  and  still  main- 
taining real-time  response  proved  quite  challenging.  The  end  result  of  this  challenge  is  affec- 
tionately known  as  "Big  Sim".  The  system  has  just  been  released  for  Firing  Room  use.  It  triples 
our  model  capacity  while  spreading  out  its  operating  system  responsibilities  so  as  not  to  signi- 
ficantly increase  processor  usage.  With  this  increased  capability,  we  are  new  able  to  integrate 
enough  system  models  to  simulate  a total  Shuttle  at  the  Pad  with  the  required  ground  support 
equipment.  For  the  first  time  we  will  have  the  capability  to  provide  launch  countdown  simulation 
with  high  fidelity  math  models.  "Big  Sim"  is  a necessary  and  welcome  addition  to  our  expanding 
collection  of  software  development  tools. 

Software  development  is  a lengthy  and  time  consuming  process.  Requirements  must  be 
generated,  software  specifications  must  be  developed,  and  the  programs  themselves  have  to  be 
coded,  debugged,  and  verified.  Each  of  these  steps  have  to  be  reviewed  and  approved.  The  whole 
process  is  complicated  even  more  by  our  overall  objectives  to  significantly  increase  the  level  of 
integration  between  systems.  The  automation  effort  requires  a substantial  committment  by  NASA 
and  its  contractors  to  supply  the  necessary  manpower  to  implement  these  concepts  that  have  been 
discussed.  This  software  development  effort  coincides  with  our  requirement  to  shorten  Shuttle 
turnaround  and  to  process  multiple  Orbiters,  E7T,  and  SRB's  in  parallel.  All  this  must  be  done 
within  the  current  manpower  ceilings  in  order  to  remain  cost-effective.  Hew  do  we  do  it? 

We  are  currently  working  on  a software  system  that  will  take  a software  specification  as 
input  and  generate  an  application  program.  The  system  is  called  LAP  (Launch  Processing  System 
Automatic  Programmer).  The  specification  document  written  in  a user  oriented  language  is  pro- 
cessed against  the  rules  of  our  Application  Software  Structure  Standard.  The  output  will  be  an 
application  program  meeting  the  software  specification  requirements  and  also  conforming  to  the 
Structure  Standard.  This  automatically  generated  program  should  be  much  easier  to  debug  because 
only  high  level  logic  needs  to  be  checked  instead  of  a module  by  module  debug.  This  system  is  in 
the  very  early  stages  of  implementation,  so  it  is  too  early  to  tell  how  efficient  the  end  product 
will  be.  Because  few  of  our  application  programs  have  been  optimized  for  speed,  we  do  not  expect 
the  inherent  degradation  of  performance  usually  associated  with  adding  another  layer  of  software 
between  the  programmer  and  computer  to  be  much  of  a problem. 

We  have  accomplished  a lot  in  our  automation  efforts  to  date,  but  the  job  is  far  from 
complete  and  we  continue  to  meet  challenges  on  a daily  basis. 
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INTRODUCTION 


Shuttle  navigation,  for  the  purpose  of  this  report,  is  defined  as  the  determination  of  Orbiter 
position,  velocity,  and  attitude  and  associated  effort.  This,  together  with  guidance,  flight  con- 
trol, consumables,  and  systems  management,  is  required  for  classical  navigation  - successful  movement 
of  a craft  from  an  initial  to  a final  destination. 

Position  and  velocity  propagation  (the  extrapolation  in  time  using  an  initial  estimate)  requires 
the  measurement  or  modeling  of  the  gravitational,  aerodynamic,  and  rocket  engine  forces  acting  on  the 
vehicle.  Position  and  velocity  determination  is  performed  using  observations  such  as  the  distance  to 
external  features,  the  rate  of  change  of  such  a distance,  and  the  direction  toward  the  feature.  On- 
board state  propagation  is  more  often  the  mode  of  state  knowledge  maintenance,  as  is  shown  in  table 
1,  since  the  ability  to  determine  position  and  velocity  using  such  observations  is  limited.  An  over- 
view of  Shuttle  navigation  is  presented  in  reference  1. 


TABLE  1.-  SHUTTLE  NAVIGATION  SYSTEM 


Navigation  systems 

Ascent 

Descent 

Orbit 

Orbiter 

State3 

Propagation 

State  propagation, 

propagation 

and  determination 

attitude  determination 

Ground 

State 

State 

Orbit 

determination 

determination 

determination 

aState:  position  and  velocity. 


By  state  is  meant  that  set  of  parameters  which  adequately  describes  the  transnational  and/or 
rotational  situation  of  the  Orbiter.  The  actual  state  parameter  set  maintained  onboard  sometimes 
includes  acceleration  and  system  biases;  however,  most  of  the  time,  it  is  limited  to  position  and 
velocity. 


CHALLENGING  AREAS 


Shuttle  navigation  as  accomplished  during  the  initial  flights  was  challenging  in  at  least  three 
respects:  the  use  of  off-the-shelf  redundant  conventional  navigation  equipment  and  the  project  goal 

to  successfully  return  the  vehicle  and  crew  after  two  nonsimultaneous  failures;  the  need  for  accurate, 
timely  ground-determined  position  and  velocity  during  ascent;  and  navigation  during  descent  from  orbit 
through  rollout. 

The  management  of  redundant  Inertial  Measurement  Units  (IMU's),  the  use  of  redundant  Tactical 
Air  Navigation  (TACAN)  equipment,  the  use  of  triple  state  maintenance,  and  the  details  of  descent  nav- 
igation have  been  presented  in  reference  2.  The  following  material  contains  a review  of  ascent 
ground  state  determination  and  selected  descent  navigation  areas. 


ASCENT  GROUND  NAVIGATION 


A ground-based  system  (state  calculation  performed  by  a ground  computer)  was  developed  to  sup- 
port the  ascent  flight  phase  during  the  interval  from  lift-off  through  about  1 minute  past  main 
engine  cutoff  (MECO).  This  system  provided  the  ground  flight  control  team  with  a capability  to  moni- 
tor onboard  navigation  system  performance  and  to  protect  engine  cutoff  conditions  as  necessary  with 
an  update  to  the  onboard  position  and  velocity.  A capability  to  update  the  onboard  state  after  MECO 
was  provided  to  protect  ascent  abort  options  - primarily  the  ability  to  return  to  a landing  site 
within  one  revolution. 
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Figure  1 shows  these  update  opportunities.  Both  C-band  (range  and  angle  observations)  and  S- 
band  (range,  Doppler,  and  angle  observations)  tracker  data  were  used  in  the  Houston  Mission  Control 
Center  (MCC)  computers  to  determine  position  and  velocity.  The  transfer  of  state  information  to  the 
Orb  iter  is  done  in  the  form  of  a correction  using  differences  between  onboard  and  ground  knowledge 
during  powered  flight.  The  onboard  state  vector  is  replaced  as  necessary  with  ground  information  dur- 
ing free  flight. 


MECO 


OMS  - ORBITAL  MANEUVERING  SYSTEM 

KSC  - KENNEDY  SPACE  CENTER 

GSFC  - GODDARD  SPACE  FLIGHT  CENTER 

FIGURE  1.-  ASCENT  STATE  UPDATE  OPPORTUNITIES. 


The  ground  pre-MECO  performance  is  shown  in  table  2.  Position  accuracy  has  been  300  to  1100 
feet,  well  below  a 6000-foot  goal.  The  critical  parameters,  radial  and  downtrack  velocity  components, 
ranged  from  3 to  20  ft/sec  and  2 to  5 ft/sec,  respectively,  compared  to  a required  accuracy  of  50  and 
40  ft/sec. 

Figure  2 is  a sketch  of  the  post-MECO  geometry.  One  minute  of  tracking  data  is  available  from 
which  to  determine  the  orbit.  During  this  time,  the  vehicle  covers  about  4°  of  travel.  The  task  is 
to  determine  the  orbit  semimajor  axis  (SMA)  to  1 nautical  mile  or  the  perigee  altitude  to  approxi- 
mately 2 nautical  miles.  The  insertion  altitude  (post-MECO)  is  approximately  60  nautical  miles  and 
the  Orbiter  skims  the  Earth  to  reach  150  to  160  nautical  miles  halfway  around,  at  which  time  a maneu- 
ver is  performed  to  circularize  the  orbit. 

An  accuracy  in  the  semimajor  axis  of  0.3  nautical  mile  or  better  has  been  achieved  as  shown  in 
table  3.  The  position  was  determined  to  a few  hundred  feet  on  most  flights.  Orbit  plane  was  deter- 
mined to  about  0.01°.  These  accuracies  were  achieved  through  the  use  of  a Kalman  filter  and  measure- 
ments from  multiple  trackers,  accurate  atmospheric  refraction  models  with  constants  reflecting  launch 
day  conditions,  and  by  including  measurement  bias  and  vehicle  thrusting  as  state  elements.  Inter- 
active controls  and  displays  allowed  for  some  inflight  ground  user  control  such  as  the  adjustment 
of  the  filter  state  noise  for  powered  versus  free  flight  and  the  assessment  of  the  quality  and 
validity  of  navigation  results. 
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TABLE  2.-  STS  ASCENT  DELTA  STATE  UPDATE  ERRORS 
(MECO  MINUS  30  SEC) 


Flight 

Position  errors,3 

ft 

Velocity  errors, 
ft/sec 

U 

V 

W 

Mag 

U 

V 

W 

Mag 

STS-1 

300 

100 

100 

330 

3 

2 

2 

5 

STS -2 

100 

50 

50 

120 

5 

3 

2 

7 

STS-3 

500 

100 

-300 

590 

10 

-5 

-5 

13 

STS -4 

1000 

500 

300 

1160 

20 

5 

5 

22 

STS -5 

-300 

200 

300 

470 

-10 

5 

7 

14 

STS -6 

500 

400 

-200 

670 

10 

5 

-5 

13 

Predicted  (3a) 

40 

20 

Required 

(3a) 

50 

40 

aU  = radial,  V = downtrack,  W = crosstrack. 
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TABLE  3.-  STS  ASCENT  GROUND  NAVIGATION  ERRORS 
(MECO  PLUS  60  SEC) 


Flight 

Position, 
U V 

ft 

W 

SMA, 
n.  mi. 

Orbital  plane, 
deg 

STS-1 

-100 

100 

40 

0.3 

0.007 

STS -2 

70 

10 

-50 

-.1 

-.012 

STS-3 

41 

31 

-58 

-.2 

.005 

STS-4 

220 

65 

30 

-.2 

.007 

STS-5 

-1350 

300 

-100 

-.3 

-.012 

STS -6 

40 

50 

40 

0 

-.005 

Predicted  (3a) 

0.5 

Required 

(3a) 

1.0 

Onboard  post-MECO  errors  are  shown  in  table  4.  The  onboard  navigation  state  has  never  been 
updated  by  the  ground  because  the  errors  are  small. 


TABLE  4.-  STS  ASCENT  ONBOARD  NAVIGATION  ERRORS 
(MECO  PLUS  60  SEC) 


Flight 

U 

Position, 

V 

ft 

W 

SMA, 
n.  mi. 

Orbital  plane, 
deg 

STS-1 

700 

-300 

-4200 

0.1 

-0.04 

STS-2 

700 

-600 

-3000 

-.5 

-.03 

STS-3 

600 

-200 

-3200 

0 

-.04 

STS-4 

300 

300 

-3200 

.1 

-.04 

STS-5 

200 

-300 

-1800 

-.1  * 

-.02 

STS-6 

-600 

100 

-2100 

-.2 

-.03 

ENTRY  NAVIGATION 


The  entry  pre-deorbit  activities  include  establishment  of  a knowledge  of  IMU  orientation  usinq 
star  trackers  and  the  transfer  of  an  accurate  state  vector  from  the  ground  to  the  Orbiter.  On  some 
flights,  there  is  provision  for  a downtrack  position  update  between  the  deorbit  maneuver  and  400  000 
feet  altitude  (entry  interface). 

Figure  3 shows  events  and  altitudes.  Use  of  altitude  data  derived  from  IMU  measurements  starts 
at  235  000  feet  altitude  and  continues  until  barometric  altimeter  data  are  used  at  about  84  000  feet. 
TACAN  range  and  bearing  data  are  used  from  about  135  000  feet  until  microwave  landing  system  data  are 
used  at  17  000  feet  altitude. 
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ENTER  DESCENT  DOWNTRACK 

NAV  SW  THREE  STATE  DEORBIT  POSITION 

STATE  VECTORS  UPDATE  MANEUVER  ADJUSTMENT  ENTRY 


BASE  VECTOR 

The  accurate  propagation  of  an  initial  state  vector  to  entry  interface  is  affected  by  trans- 
lational effects  from  rotational  maneuvers,  drag,  and  vehicle  outgassing  or  venting.  These  effects 
were  reduced  by  procedures  designed  to  minimize  the  time  between  ground  state  determination  and  entry 
interface,  minimizing  the  rotational  maneuvers,  and  use  of  attitude-dependent  drag  force  models. 

The  position  accuracy  at  entry  interface  has  ranged  from  0.2  to  0.8  nautical  mile.  This  is 
small  compared  to  a 5-nautical  mile  3a  predicted  accuracy  because  the  propagation  interval  was 
greatly  reduced  from  that  originally  expected. 


DOWNTRACK  ADJUSTMENT 

A capability  was  developed  to  quickly  determine  downtrack  position  and  adjust  the  onboard  vector 
if  necessary  in  the  region  between  the  deorbit  maneuver  and  entry  interface.  The  procedure  is  to  use 
S-band  range  and  Doppler  data  directly  to  determine  the  downtrack  position  error  in  the  onboard  state 
and  then  calculate  the  adjustment  to  the  onboard  vector  timetag  required  to  move  the  estimate  of  posi- 
tion forward  or  back  along  the  orbit  path.  The  timetag  adjustment  is  voiced  to  the  flightcrew  for 
manual  entry  into  the  onboard  computer. 

The  range  measurement  is  used  at  vehicle  acquisition  near  the  horizon,  at  which  point  most  of  the 
downtrack  position  error  is  reflected  in  the  differences  between  the  observed  range  and  the  range  com- 
puted using  the  onboard  state  vector  (fig.  4). 
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RANGE 


RANGE  RATE 


FIGURE  4.-  DOWNTRACK  POSITION  ADJUSTMENT  TECHNIQUE. 


The  Doppler  measurement  is  zero  as  the  vehicle  passes  by  the  site  which,  given  good  orbit  shape 
and  plane  information,  enables  downtrack  position  to  be  easily  determined.  The  two  independent  deter- 
minations of  downtrack  position  are  compared.  No  adjustment  has  been  made  on  any  of  the  flights  to 
date  because  of  the  very  small  errors  in  the  base  vector.  The  adjustment  technique  has  been  accurate 
to  at  least  1000  feet  (0.04  second). 


I MU  ORIENTATION 

The  IMU  orientation  accuracy  requirement  for  descent  support  is  0.53°  with  a design  goal  to  pro- 
vide for  desired  system  performance  margins  of  0.26  deg/axis.  Orientation  knowledge  is  accurate  to 
about  0.06  deg/axis  la  using  the  star  tracker  for  initial  determination  and  0.08  deg/axis  la  using  a 
crew  optical  alinement  system.  These  accuracies  allow  for  3.3  hours  of  IM1  drift  from  the  last  aline- 
ment  to  entry  interface.  IMU  drifts  are  calibrated  in  flight  by  the  ground.  Typical  calibrated  drift 
rate  errors  are  about  0.02  deg./hr/axis.  IMU  alinement  on  Apollo  was  performed  using  a manually  oper- 
ated sextant.  Use  of  the  automatic  star  tracker  has  also  been  very  successful. 


DESCENT  NAVIGATION 


RADIAL  POSITION  ERROR  AND  IMU  MEASUREMENTS 

State  propagation  with  the  use  of  velocity  change  due  to  contact  forces  measured  by  the  IMU  and 
gravitational  acceleration  models  was  expected  to  result  in  large  errors  in  radial  position  during  de- 
scent. A method  for  constraining  the  size  of  the  radial  position  and  velocity  error  was  desired  to 
minimize  position  transients  at  TACAN  acquisition  and  to  provide  good  radial  rate  information  for 
guidance.  The  approach  taken  is  shown  in  figure  5.  Drag  acceleration,  measured  by  the  IMU,  is  a 
function  of  vehicle  speed,  mass,  area,  and  atmospheric  density.  Atmospheric  density  decreases 
exponentially  with  altitude.  Altitude  was  computed  given  the  other  parameters  and  provided  to  a navi- 
gation filter  as  an  observation  for  state  determination.  This  approach  was  expected  to  degrade  IMU 
altitude  knowledge  for  normal  IMU  performance  at  higher  altitudes  but  to  improve  on  it  at  lower  al- 
titudes. This  prediction  can  be  seen  in  figure  6.  A shift  in  the  predicted  error  (mean  +3a!  in  ra- 
dial position  occurs  at  initial  use  of  the  derived  altitude  at  about  230  000  feet  altitude.  The 
predicted  errors  apply  for  all  of  the  flights  shown  except  flight  4.  Flight  4 occurred  in  July  and 
the  uncertainty  in  atmospheric  density  is  expected  to  be  worse  than  for  cooler  seasons.  Use  of  de- 
rived altitude  worked  as  predicted.  The  altitude  error  is  less  than  1 nautical  mile  throughout  de- 
scent. 
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ATMOSPHERE 


DENSITY  DECREASES  WITH  ALTITUDE 


DRAG  DECELERATION  - 
DEPENDS  ON  RELATIVE 
SPEED,  VEHICLE 
AREA,  AND  MASS 
ATMOSPHERIC  DENSITY 


DETERMINE  ALTITUDE  USING  IMU  MEASUREMENTS  OF  DECELERATION 
PROCESS  ALTITUDE  INFORMATION  IN  NAVIGATION  FILTER 

FIGURE  5.-  DESCENT  ALTITUDE  AND  DOWNTRACK  POSITION 
ERROR  RESTRAINT  TECHNIQUE. 


250  000  200  000  150  000  100  000  50  000  0 

ALTITUDE  ABOVE  RUNWAY,  FT 


TRACE  = FLIGHT  NUMBER 
+ = M + 3 SAMPLE  STD  DEV  a 
- = M - 3 SAMPLE  STD  DEVa 
G = GUIDANCE  CONSTRAINT 


^PREDICTED 


FIGURE  6.-  ERROR  IN  RADIAL  POSITION. 
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DESCENT  STATE  DETERMINATION  USING  TACAN  AND  MICROWAVE  DATA 


Some  effect  on  radial  position  accuracy  from  the  use  of  TACAN  range  data  can  be  seen  (fig.  61  in 
the  130  000-foot-altitude  region.  The  TACAN  ground  site  is  near  the  runway  and  the  line  of  sight  be- 
tween it  and  the  Orb iter  is  more  toward  the  horizontal  than  the  vertical.  The  result  is  limited  di- 
rect visibility  of  radial  position  and  limited  ability  to  correct  it.  Use  of  barometric  altimeter 
data  at  about  84  000  feet  altitude  reduces  radial  position  error  to  less  than  500  feet  by  the  time 
landing  system  measurements  are  available.  Use  of  microwave  landing  system  data  at  about  17  000  feet 
altitude  reduces  the  position  error  to  less  than  100  feet.  Radial  position  guidance  requirements 
have  been  met  with  good  margins. 

The  use  of  derived  altitude  affects  downtrack  position  because  radial  and  downtrack  position 
errors  are  correlated  (fig.  7).  The  use  of  TACAN  observations  easily  reduces  downrange  position 
errors  to  less  than  3000  by  120  000  feet  altitude. 

Crosstrack  position  error  is  shown  in  figure  8 as  a function  of  altitude.  A 1.2°  TACAN  bearing 
error  on  flight  1 led  to  an  8000-foot  crosstrack  error  at  about  115  000  feet  altitude.  The  error 
decreased  with  decreasing  range  to  the  TACAN  site.  Otherwise,  the  crosstrack  error  was  less  than  t 
nautical  mile  throughout  descent. 


ALTITUDE  ABOVE  RUNWAY,  FT 


TRACE  = FLIGHT  NUMBER 
+ = M + 3 SAMPLE  STD  DEV 
- = M - 3 SAMPLE  STD  DEV 
G = GUIDANCE  CONSTRAINT 


FIGURE  7.-  ERROR  IN  DOWNRANGE  POSITION. 
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ALTITUDE  ABOVE  RUNWAY,  FT 


TRACE  = FLIGHT  NUMBER 
+ = M + 3 SAMPLE  STD  DEV 
- = M - 3 SAMPLE  STD  DEV 
G = GUIDANCE  CONSTRAINT 


FIGURE  8.-  ERROR  IN  CROSSRANGE  POSITION. 


The  error  information  for  selected  times  is  provided  in  tables  5 to  7.  Table  7 shows  an  improve- 
ment at  touchdown  on  flight  6 due  to  the  use  of  a microwave  landing  system  ground  antenna  that  was 
more  compatible  with  the  Orbiter  antenna.  The  vertical  error  on  flight  2 at  touchdown  is  the  result 
of  using  microwave  landing  system  elevation  data  at  too  low  an  elevation  so  that  multipath  error  ef- 
fects deteriorated  the  state. 


AIR  RELATIVE  DATA 


Air  relative  parameters  - Mach  number,  angle  of  attack,  and  dynamic  pressure  - are  required  for 
flight  control  prior  to  air  data  availability  at  about  84  000  feet  altitude.  There  was  a desire  to 
have  the  vehicle  control  be  independent  of  position  and  velocity  error.  Use  of  drag  acceleration 
measured  by  the  IMU's  for  the  computation  of  air  relative  parameters  resulted  in  relatively  accurate 
parameters  with  only  second-order  dependence  on  position  and  velocity. 


FUTURE  NAVIGATION  EFFORT 


New  capabilities  planned  include  navigation  for  rendezvous  and  proximity  operations  and  refined 
orbital  onboard  state  propagation  in  1984;  flexibility  ahd  reduced  onboard  maintenance  of  runway, 
TACAN,  and  microwave  site  data  in  1985;  and  autonomous  orbital  navigation  by  1986.  There  will  be 
three  additional  vehicles  to  check,  a first  KSC  landing,  a Vandenberg  launch,  a Vandenberg  landing, 
and  an  automatic  landing.  The  first  use  of  the  Tracking  and  Data  Relay  Satellite  fTDRSl  for  ground- 
based  orbital  navigation  will  occur  in  1983.  Onboard  descent  autonomy  requires  autonomous  orbital 
navigation,  deorbit  targeting,  and  independence  from  current  ground  management  of  the  use  of  onboard 
descent  navigation  sensors. 
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TABLE  5.-  ONBOARD  NAVIGATION  SUMMARY  NEAR  TACAN  ACQUISITION 


Pre-TACAN 

Post-TACAN 

Flight 

Position, 

, ft 

Flight 

Position, 

ft 

Horizontal 

Vertical 

Horizontal  Vertical 

STS-l 

5 822 

-696 

STS-l 

4349 

-467 

STS-2 

1 452 

2021 

STS-2 

1230 

998 

STS -3 

11  834 

1831 

STS -3 

2460 

728 

STS-4 

15  458 

-5858 

STS-4 

2609 

-3903 

STS -5 

4 050 

3720 

STS -5 

2262 

1625 

STS-6 

6 334 

-1860 

STS-6 

1052 

-1241 

Mean  +laa 

10  602 

2269 

Mean  +la 

3326 

2291 

Mean  +3a 

27  066 

5903 

Mean  +3cr 

9980 

6134 

aExpected. 

TABLE  6.-  ONBOARD 

NAVIGATION 

SUMMARY  NEAR  MSBLS  ACQUISITION 

Pre-MSBLS 

Post-MSBLS 

Flight 

Position, 

ft 

Flight 

Position, 

ft 

Horizontal 

Vertical 

Horizontal  Vertical 

STS-l 

877 

303 

STS-l 

36 

51 

STS-2 

1113 

-488 

STS-2 

120 

51 

STS -3 

1386 

-6 

STS -3 

14 

-54 

STS-4 

320 

411 

STS-4 

54 

78 

STS -5 

750 

194 

STS -5 

83 

23 

STS-6 

1220 

440 

STS-6 

102 

74 

Mean  +laa 

470 

420 

Mean  +la 

67 

43 

Mean  +3a 

1230 

1213 

Mean  +3a 

198 

99 

aExpected. 
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TABLE  7.-  ONBOARD  NAVIGATION  SUMMARY  AT  TOUCHDOWN 


Flight 

Touchdown,  ft 

Downtrack 

Crosstrack 

Vertical 

STS-1 

-4 

18 

5 

STS-2 

36 

50 

15 

STS-3 

32 

72 

6 

STS-4 

19 

48 

6 

STS-5 

10 

29 

2 

STS -6 

20 

4 

4 

Mean  +3aa 

48 

30 

30 

aExpected. 
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ABSTRACT 


The  Space  Shuttle  descent  mission  planning,  mission  design,  deorbit  targeting,  and  entry  guid- 
ance have  necessarily  become  interrelated  because  of  the  nature  of  the  Orbiter's  design  and  mission 
requirements.  The  desired  descent  trajectory  has  been  formulated  in  a drag  acceleration/relative  ve- 
locity state  space  since  nearly  all  of  the  vehicle's  highly  constraining  flight  limitations  can  be 
uniquely  represented  in  this  plane.  This  paper  presents  a description  of  these  constraints  along 
with  the  flight  requirements  that  affect  them,  a discussion  of  the  guidance  logic  which  allows  the 
Orbiter  to  follow  the  designed  trajectory,  and  a summary  of  the  impacts  of  contingency  aborts  and 
flightcrew  interaction.  The  mission  planning  and  guidance  techniques  have  remained  essentially 
unchanged  through  the  Shuttle  flight  test  program  and  subsequent  operational  flights.  No  problems  or 
anomalies  have  been  observed  in  these  areas. 


INTRODUCTION 


The  experience  gained  in  developing  the  Gemini  and  Apollo  entry  mission  plans,  flight  software, 
and  trajectory  monitoring  procedures  has  provided  insight  into  the  problems  encountered  during  the 
atmospheric  descent  of  a manned  spacecraft.  The  Shuttle  Orbiter  shares  many  requirements  and  con- 
straints with  these  earlier  vehicles.  A flightpath  must  be  maintained  that  causes  no  violations  of 
the  spacecraft's  thermal  or  load  limits  yet  ensures  atmospheric  capture  and  stable  flight.  Allowance 
must  be  made  for  uncertainties  in  atmospheric  properties,  navigational  accuracies,  and  aerodynamic 
characteristics.  The  vehicle  and  crew  must  be  able  to  function  autonomously  because  of  communication 
blackout  and  limited  ground  coverage.  Finally,  the  spacecraft  must  be  delivered  to  a specified  loca- 
tion and  energy  state  with  the  required  precision. 

Although  the  general  nature  of  these  requirements  for  manned  reentry  vehicles  is  similar,  be- 
cause of  the  Orbiter's  basic  design,  nearly  all  of  Its  flight  constraints  are  significantly  more 
limiting  than  those  of  previous  spacecraft,  and  Its  mission  is  more  complex.  In  addition  to  the  nor- 
mal end-of -mission  functions,  the  Shuttle's  entry  system  must  support  the  needs  of  transoceanic  abort 
landing  (TAL)  and  abort  once  around  (AOA)  contingencies.  These  factors  Imply  a wide  range  of  vehicle 
weights  and  center- of- gravity  (c.g.)  locations  and  have  made  It  necessary  to  Implement  a complex  guid- 
ance scheme  with  greater  flexibility  than  that  of  either  the  Gemini  or  the  Apollo  vehicle. 

The  development  of  the  guidance  logic  and  the  selection  of  a basic  flight  profile  are  closely  re- 
lated through  the  Shuttle  descent  mission  planning.  Therefore,  the  effects  of  both  mission  require- 
ments and  guidance  system  characteristics  are  addressed. 


ENTRY  CONFIGURATION 


During  the  early  phases  of  entry  (before  active  auidance),  attitude  control  in  all  vehicle  axes 
is  maintained  by  the  Orbiter  reaction  control  system  (RCS).  To  avoid  unacceptable  aerothermodynamic 
heating,  especially  on  the  upper  surface  and  wing  leading  edge,  a 40°  angle  of  attack  is  flown  during 
the  high-speed  flight  regime  (Mach  > 14).  Even  though  this  value  is  far  on  the  back  side  of  the 
lift-to-drag  ratio  (L/D)  curve,  it  still  results  In  a much  higher  L/D  than  for  previously  flown 
manned  reentry  vehicles.  Figure  1 shows  the  overall  aerodynamic  characteristics  on  a typical  Orbiter 
entry  trajectory  (ref.  1). 

When  sufficient  atmospheric  dynamic  pressure  has  been  achieved,  attitude  control  is  transferred 
to  the  aerodynamic  control  surfaces  (aero surf aces).  At  a navigation-sensed  dynamic  pressure  of  10 
psf,  the  roll  RCS  jets  are  deactivated  and  differential  elevon  deflections  control  motion  about  that 
axis.  When  the  dynamic  pressure  exceeds  20  psf,  control  by  the  elevator  in  the  form  of  symmetric 
elevon  deflections  replaces  the  pitch  jets.  As  Is  Indicated  later,  the  primary  maneuvers  performed 
during  entry  are  rotations  about  the  vehicle  velocity  vector.  These  maneuvers  amount  to  coordinated 
roll  and  yaw  rates  about  the  spacecraft  body  axes.  Because  of  the  large  angle  of  attack,  the  verti- 
cal stabilizer  is  not  an  effective  aerosurface  during  high-speed  flight;  therefore,  the  maneuvers  re- 
quire a combination  of  aft  yaw  RCS  jets  and  ailerons.  The  yaw  jets  operate  throughout  entry. 

In  addition  to  providing  active  vehicle  control  (l.e.,  the  Orbiter  Is  statically  unstable  during 
much  of  its  flight),  the  flight  control  system  must  compensate  for  variations  In  pitching  moment  due 
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FIGURE  1.-  TYPICAL  ORBITER  AERODYNAMIC  CHARACTERISTICS. 


to  shifts  in  the  spacecraft  center  of  gravity  and  aerodynamic  moments.  To  maintain  the  elevons  in 
a thermally  benign  position  where  they  are  aerodyn ami  call y effective  for  lateral  control,  the  large 
aft  body  flap  is  used  for  pitch  trim.  The  ailerons  trim  out  any  lateral  c.g.  effects. 


ENTRY  CORRIDOR 


Entry  imposes  on  a returning  vehicle  certain  physical  conditions,  the  severity  of  which  depends 
on  the  particular  trajectory  flown.  In  general,  for  a given  entry  velocity,  a steep  flightpath  angle 
implies  high  surface  temperatures  and  aerodynamic  load  factors,  whereas  a shallow  flightpath  angle 
can  result  in  poor  trajectory  control  (phugoids)  or  atmospheric  ski  pout.  The  width  of  the  entry  cor- 
ridor is  a function  of  such  vehicle  capabilities  as  thermal  and  structural  constraints  and  aerodynamic 
characteristics.  Figure  2 shows  the  entry  corridors  for  the  Apollo  command  module  (CM)  and  the  Shuttle 
Orbiter  (ref.  2).  Both  are  defined  by  the  flightpath  angle  and  the  inertial  velocity  at  entry  interface 
(400  000  feet  altitude).  It  is  apparent  that  the  Shuttle  thermal  limits  impose  severe  restrictions  on 
the  entry  corridor  and  place  stringent  requirements  on  entry  targeting  and  guidance. 


DEORBIT  TARGETING 

The  Shuttle  orbital  maneuvering  system  (QMS)  performs  a single  deorbit  burn  to  arrive  at  entry 
interface.  The  result  is  a specific  combination  of  velocity,  flightpath  angle,  and  range  to  go,  which 
depend  on  the  orbital  altitude  and  burn  characteristics.  To  cover  the  range  of  Shuttle  operational 
orbits  (as  high  as  500  nautical  miles),  a target  line  is  generated  in  the  V-Y  plane  representing  a 
set  of  acceptable  entry  interface  (El)  conditions.  The  intersection  of  this  target  line  with  the  ap- 
propriate deorbit  curve  defines  the  target  state.  The  range  to  the  target  is  controlled  by  properly 
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FIGURE  2.-  APOLLO  COMMAND  MODULE  AND  SHUTTLE  ORB ITER  ENTRY  CORRIDORS. 


timing  the  burn.  The  segment  of  the  entry  from  El  to  active  guidance  initiation  is  normally  flown  at 
a wings-level  attitude  (steep  target).  In  the  event  of  a fuel-critical  deorbit  or  an  OMS  underburn, 
a bank  angle  as  great  as  90°  can  be  commanded  (shallow  target).  This  prebank  has  the  effect  of 
steepening  the  early  trajectory  by  dumping  lift.  Typical  steep  and  shallow  target  lines  and  the 
transfer-orbit  curves  are  shown  in  figure  3.  The  onboard  deorbit  guidance  actually  targets  the  line 
rather  than  the  intersection,  so  that  any  deviation  from  the  ideal  transfer  still  results  in  accept- 
able entry  conditions.  The  target  lines  themselves  represent  El  states  which  allow  the  trajectory  to 
converge  to  preplanned  entry  profiles  (to  be  discussed  later).  For  steep  targets,  the  line  is  adjusted 
to  optimally  trade  surface  temperatures  against  high  backface  temperatures;  the  latter  temperatures 
are  caused  by  the  large  heat  loads  generated  during  long,  shallow  glides. 

ha- APOGEE  ALTITUDE 


FIGURE  3.-  STEEP  AND  SHALLOW  TARGET  LINES. 
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TRAJECTORY  CONSTRAINTS 


Once  the  Orbiter  has  achieved  the  desired  El  state,  it  is  still  necessary  to  actively  guide  the 
vehicle  to  the  landing  site  while  remaining  within  trajectory  and  vehicle  limits.  The  various  con- 
straint boundaries  become  binding  at  different  flight  conditions,  and  their  interaction  can  be  com- 
plex. To  visualize  the  profile  that  must  be  flown,  the  constraints  must  be  formulated  as  functions 
of  the  proper  trajectory  variables. 

For  thermal  and  flight  control  system  considerations,  the  Orbiter  angle  of  attack  (and  therefore 
its  aerodynamic  characteristics)  has  been  scheduled  as  a function  of  Earth  relative  velocity.  Figure 
4 shows  the  profile  used  in  the  majority  of  Shuttle  flights.  The  ramp  beginning  at  a velocity  of 
14  500  ft/s  delivers  the  Orbiter  to  the  terminal  area  energy  management  (TAEM)  interface  (2500  ft/s) 
on  the  front  side  of  the  L/D  curve,  where  more  conventional  aircraft-type  control  is  employed. 
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FIGURE  4.-  ORBITER  ANGLE  OF  ATTACK  PROFILE. 


The  most  critical  constraints  during  early  entry  are  the  thermal  protection  system  (TPS)  surface 
temperatures.  For  a fixed  angle-of-attack  profile,  large  dynamic  pressures  and  relative  velocities 
will  elevate  surface  temperatures.  Since  the  aerodynamic  flow  field  over  the  Orbiter's  surface  is 
complex,  mathematical  models  representing  heat  rates  on  specific  vehicle  locations  or  control  points 
are  used  for  trajectory  design  (ref.  3).  Figure  5 depicts  the  positions  of  several  control  points. 
Depending  on  the  particular  flight  condition  and  the  maximum  allowable  temperature  at  each  point,  any 
of  these  locations  may  represent  the  limiting  constraint  on  the  trajectory. 

To  ensure  stable,  nonosci llatory  flight,  a design  requirement  has  been  implemented  to  guarantee 
that  the  Orbiter  flightpath  angle  is  always  decreasing,  that  is,  that  the  trajectory  is  constantly 
becoming  steeper.  The  limiting  case,  where  Y = 0,  defines  the  equilibrium  glide  boundary.  Physi- 
cally, this  value  corresponds  to  the  flight  condition  in  which  the  vertical  component  of  the  vehicle 
lift  acceleration  plus  the  centripetal  acceleration  induced  by  the  high  velocity  are  balanced  by  grav- 
ity. For  a given  bank  angle,  the  constraint  can  be  expressed  as  a function  of  dynamic  pressure  and 
inertial  velocity  since  they  determine  the  magnitudes  of  lift  and  centripetal  acceleration,  respec- 
tively. The  value  of  the  minimum  allowable  bank  angle  resulted  from  trade  studies  evaluating  the  hor- 
izontal lift  component  necessary  for  Orbiter  crossranging  requirements. 
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FIGURE  5.-  CONTROL  POINT  GEOMETRY. 


The  Shuttle  Orbiter  is  also  much  more  limited  in  its  maximum  allowable  load  factor  than  were  pre- 
vious reentry  vehicles.  Gemini  and  Apollo  spacecraft  operated  at  4g  to  7g  with  a design  limit  of 
12g  on  the  Apollo  CM  (refs.  4 and  5).  In  contrast,  the  Orbiter  was  designed  with  a maximum  normal 
load  factor  of  2.5g  and  a trajectory-shaping  goal  of  1.5g.  The  actual  load  factor  encountered  de- 
pends only  on  the  normal  acceleration  magnitudes  or,  equivalently,  on  angle  of  attack  and  dynamic 
pressure.  During  lower  speed  portions  of  the  entry  (3500  to  2500  ft/s),  dynamic  pressure  becomes  a 
constraint  because  of  its  effects  on  wing  loading  and  aerosurface  hinge  moments. 

All  of  these  constraints  could  be  portrayed  in  a dynamic  pressure/velocity  state  space.  Use  of 
dynamic  pressure  as  a guidance  control  parameter  would  involve  derivation  from  sensed  vehicle  acceler- 
ations and  attitudes  and  would  require  lift  and  drag  coefficient  models  for  all  valid  angles  of  at- 
tack and  Mach  numbers.  Since  considerable  uncertainties  existed  in  the  preflight  predictions  of 
these  quantities,  the  constraint  boundaries  were  reformulated  into  a drag  acceleration/Earth  relative 
velocity  state  space.  This  formulation  requires  only  an  estimate  of  the  Orbiter  lift-to-drag  ratio, 
which  is  probably  the  most  reliable  aerodynamic  parameter  to  predict  and  can  also  be  directly  meas- 
ured during  flight.  In  addition,  a drag  acceleration  profile  uniquely  defines  the  range  flown  during 
entry.  Figure  6 depicts  the  surface  temperature,  equilibrium  glide,  load  factor,  and  dynamic  pres- 
sure constraints  in  this  plane  for  typical  mission  parameters.  To  accomplish  a safe  entry,  the 
Orbiter  must  fly  the  corridor  between  these  constraint  boundaries. 

The  corridor  width,  and  therefore  the  safety  margins  of  the  entry  flightpath,  depends  on  spe- 
cific mission  characteristics.  The  Space  Shuttle  must  operate  over  large  variations  of  orbital  incli- 
nation, vehicle  weight,  and  center-of-gravity  location.  Inclination  affects  the  relationship  between 
inertial  and  Earth  relative  velocity  and  shifts  the  equilibrium  glide  constraint  in  the  D-V  plane; 
the  corridor  narrows  for  increasing  inclination.  Vehicle  weight  is  the  driver  on  the  location  of  all 
the  surface  temperature  boundaries.  An  increase  in  weight  narrows  the  corridor  as  the  Orbiter  must 
fly  a trajectory  consistent  with  larger  aerodynamic  forces  to  produce  equivalent  accelerations.  The 
change  in  these  constraint  boundaries  can  be  seen  in  figure  7.  As  the  c.g.  shifts,  the  body  flap 
must  deflect  to  trim  the  vehicle  and  thereby  alters  the  airflow  and  thermal  distribution  on  that  sur- 
face. An  aft  c.g.  deflects  the  body  flap  down  into  the  airflow  and  increases  the  temperature  of  the 
associated  control  point  as  shown  in  figure  8.  In  practice,  the  elevon  and  predicted  body  flap  posi- 
tions are  balanced  so  that  neither  surface  temperature  is  excessively  more  restricting  than  the  other. 
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EARTH  RELATIVE  VELOCITY,  FT/S 

FIGURE  6.-  REPRESENTATIVE  CONSTRAINT  BOUNDARIES. 


FIGURE  7.-  EFFECTS  OF  WEIGHT  AND  INCLINATION  ON  FIGURE  8.-  EFFECT  OF  CENTER  OF  GRAVITY  ON  CON- 
CONSTRAINT  BOUNDARIES.  STRAINT  BOUNDARIES. 


The  combination  of  the  effects  of  these  mission  parameters  can  be  seen  in  the  constraint  bound- 
aries of  a "worst  case"  entry.  As  shown  in  figure  9,  essentially  no  corridor  remains. 
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FIGURE  9.-  "WORST  CASE"  CONSTRAINT  BOUNDARIES. 


GUIDANCE  LOGIC 


The  engineering  challenge  addressed  in  designing  the  entry  guidance  was  to  devise  a method  for 
directing  the  Orbiter  along  a trajectory  which  remained  within  the  highly  confining  constraint  corri- 
dor using  primarily  the  onboard  navigation  while  still  allowing  enough  flexibility  to  arrive  at  the 
landing  site  with  the  proper  energy  reserve.  Achievement  of  this  objective  was  made  possible  by  the 
realization  that  the  drag  acceleration/relative  velocity  plane  was  the  proper  state  space  in  which 
to  view  the  constraints  and  define  the  entry  range . It  then  became  natural  to  implement  the  guidance 
logic  in  this  plane  also  (ref.  6).  Figure  10  depicts  a typical  drag  profile,  which  represents  the 
desired  entry  trajectory  for  the  boundaries  in  figure  6. 


ENTRY  PROFILE 

To  remain  within  the  constraint  corridor,  the  guidance  has  been  divided  into  four  phases.  The 
temperature  control  phase  is  initiated  at  a vehicle  load  factor  of  0.176g  and  continues  as  long  as 
surface  temperatures  are  the  binding  constraints.  At  a relative  velocity  of  17  000  ft/s,  a pseudo- 
equilibrium glide  phase  is  entered  for  a short  time  to  deliver  the  vehicle  to  the  flight  region  in 
which  load  factor  limits  deceleration.  A constant-drag  phase  designed  to  produce  a 1.5g  total  load 
factor  is  then  followed  until  the  Orbiter  pitch  down  and  associated  L/D  increase  requires  a lower  de- 
celeration level.  The  transition  phase  completes  the  entry  and  delivers  the  spacecraft  to  the  de- 
sired energy  state  at  TAEM  interface.  All  guidance  phases  are  defined  by  simple  geometry  in  the  D-V 
plane,  and  15  constraints  mathematically  describe  the  entire  entry  profile.  It  is  the  task  of  de- 
scent mission  planning  to  select  this  profile  based  on  its  capability  to  accommodate  nominal  and  all 
foreseen  stress  requirements. 
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FIGURE  10.-  DRAG  PROFILE  AND  CONSTRAINTS. 


The  flightpath  resulting  from  the  profile  of  figure  10  Is  shown  In  figure  11  along  with  typical 
Apollo  and  Gemini  descents  (refs.  7 and  8).  It  Is  obvious  that  an  extended  high-altitude  glide  Is 
the  direct  result  of  the  thermal  and  load  factor  limitations.  This  long  flight  time  produces  a 
backface  temperature  constraint  which  Is  not  uniquely  defined  In  the  D-V  plane.  The  TPS  was  sized  on 
the  basis  of  a reference  heat  load,  and  any  Increase  In  this  value  has  a direct  bearing  on  the  tem- 
perature of  the  Orb  Iter's  aluminum  structure.  Procedures  such  as  on-orbit  shading  of  the  lower  sur- 
face before  entry  help  alleviate  this  heat  soak,  but.  In  practice,  the  constraint  on  backface  tempera- 
ture Is  more  binding  than  the  equilibrium  glide  boundary. 


TRAJECTORY  CONTROL 

Once  a reference  profile  with  the  proper  range  potential  has  been  designed,  a method  of  com- 
manding flight  control  and  correcting  for  deviations  must  be  devised.  Recall  that  the  only  vehicle 
characteristic  necessary  to  define  a path  in  the  D-V  plane  is  the  vertical  component  of  the  lift-to- 
drag  ratio,  L/Dv.  Conversely,  a reference  L/Dv  corresponding  to  the  reference  drag  profile  can  be 
computed.  Since  the  total  vehicle  L/D  is  scheduled  with  velocity  (through  angle  of  attack),  this 
L/Dv  is  achieved  by  rotating  the  lift  vector  about  the  velocity  vector  through  a stability  bank  angle 
with  magnitude 

♦s'C0!'1  [ttt  ] ' 


Also,  because  the  in-flight  L/D  can  be  measured  directly  by  the  onboard  navigation,  the  vertical  com- 
ponent can  be  precisely  controlled. 

To  compensate  for  deviations  from  the  drag  profile,  a drag  error  feedback  term  was  Introduced 
Into  the  commanded  L/Dv  equation.  It  is  usually  desirable  to  include  a lead  term  in  a feedback  control 
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FIGURE  11.-  FLIGHTPATH  COMPARISONS. 


system,  but  accelerometer  noise  and  small  vehicle  attitude  changes  make  the  time  derivative  of  drag 
an  unsuitable  measurement  without  significant  filtering.  After  appropriate  manipulation,  altitude 
rate  (h)  can  be  used  as  a measure  of  the  drag  rate  due  to  trajectory  effects  only,  and  a reference 
h profile  can  be  analytically  constructed  from  the  reference  drag  profile.  The  final  form  of  the 
vertical  L/D  command  equation  is 


L^vC0MMAND  = + k[)  (D  - Drep)  + (h  - Href ) 

where  kn  and  kfi  are  appropriate  system  gains.  Again,  this  expression  is  implemented  through 
a stability  bank  angle  command. 


RANGE  PREDICTION 

As  has  been  stated  earlier,  the  reference  drag  profile  uniquely  defines  the  range  remaining  to 
be  flown  from  a given  velocity.  This  range  prediction,  based  on  approximations  to  the  equations  of 
motion,  is  compared  with  the  navigation-based  range-to-go  value  to  form  an  error  term  used  to  adjust 
the  current  drag  profile  as  follows:  increase  it  if  the  Orbiter  is  too  close  to  the  target,  decrease 

it  if  it  is  too  far.  Thus,  in  effect,  an  outer  feedback  loop  which  continually  updates  the  original 
reference  profile  is  formed.  Operationally,  it  is  desirable  to  preserve  as  much  ranging  capability 
as  possible  late  in  the  entry  to  allow  for  postblackout  navigation  updates  and  runway  redesignations. 
Therefore,  only  the  current  guidance  phase  of  the  profile  is  adjusted  for  ranging  and,  consequently, 
the  Orbiter  is  forced  back  toward  the  center  of  the  ranging  footprint  (ref.  9). 


CROSSRANGE  CONTROL 

Because  a bank  angle  must  be  maintained  to  achieve  the  proper  vertical  trajectory,  the  horizon- 
tal component  of  lift  can  be  used  to  turn  the  flightpath.  The  relatively  high  Orbiter  L/D  allows  a 
much  larger  crossranging  capability  than  with  previous  vehicles,  approximately  750  nautical  miles. 
This  capability  greatly  aids  operational  factors  such  as  the  number  of  return  opportunities  into  a 
given  landing  site  and  abort-once-around  contingencies.  To  target  for  the  proper  crossrange,  the 
guidance  computes  the  azimuth  error  between  the  velocity  vector  and  the  line  of  sight  to  the  runway. 
If  this  angle  becomes  greater  than  a stored  deadband  schedule,  a bank  reversal  is  commanded. 

The  trajectory  is  essentially  uncontrolled  during  a reversal,  and  some  lofting  occurs  because  of 
the  Orbiter's  maximum  roll  rate  of  only  5 deg/s.  This  lofting  would  cause  the  drag  level  to  drop 
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below  the  reference  profile;  consequently,  compensation  has  been  added  to  the  guidance  pitch  channel 
by  which  the  angle  of  attack  and,  therefore,  the  drag  coefficient  is  allowed  to  increase  for  driving 
the  vehicle  back  to  the  reference.  This  modulation  also  decreases  the  effect  of  any  unforeseen  atmos- 
pheric density  gradients.  Typical  altitude  rate,  roll,  and  angle-of-attack  histories  are  shown  in 
figure  12.  The  result  is  very  tight  drag  trajectory  control  as  shown  in  figure  13. 


FIGURE  12.-  FLIGHT  DATA  PARAMETERS  FROM  STS-5.  FIGURE  13.-  DRAG  AND  REFERENCE  PROFILE,  STS-6. 


CONTINGENCY  ABORTS 


The  guidance,  in  addition  to  providing  trajectory  control  for  nominal  and  dispersed  end-of- 
mission  entries,  must  allow  intact  vehicle  recovery  for  mission  emergencies  and  aborts.  The  logic 
has  been  adapted  for  two  contingencies:  abort  once  around  and  transoceanic  abort  landings. 

An  AOA  results  from  main  propulsion  system  (MPS)  failures  during  ascent  which  prevent  nominal 
orbit  insertion  or  Orbiter  system  failures  which  dictate  immediate  return  to  Earth.  The  latter  usu- 
ally involves  a rather  standard  entry,  although  thermal  loads  may  be  more  severe  since  there  has 
been  no  time  to  dissipate  ascent  heating  and  the  vehicle  weight  is  usually  higher.  To  compensate, 
the  guidance  drag  profile  is  lowered.  An  MPS  failure  implies  that  the  Orbiter  may  achieve  entry 
interface  with  a shallow  flightpath  angle  (perhaps  necessitating  entry  prebank)  with  high  heat  loads 
resulting  from  the  long-range,  shallow  trajectory.  Still,  the  AOA  falls  into  nearly  the  same  region 
as  dispersed  end-of -mission  entries,  and  no  modifications  to  the  guidance  software  have  been  neces- 
sary to  support  it. 

A TAL  is  caused  by  one-  or  two-engine  MPS  failures  during  ascent  and  involves  targeting  for  and 
flying  to  a downrange  landing  site.  The  TAL  concept  originated  when  flightcrews  noticed  during  as- 
cent simulations  that  entry-type  energy-range  conditions  were  often  achieved.  Although  this  observa- 
tion is  essentially  true,  the  flight  conditions  during  a TAL  are  similar  to  a very  steep,  low-energy 
entry,  which  would  place  extreme  thermal  stresses  on  the  Orbiter.  Figure  14  shows  the  vehicle  drag 
and  drag  profile  resulting  from  a TAL  simulation.  The  entry  is  so  steep  that  even  lift-vector-up 
flight  produces  a large  drag  pulse  and  the  associated  high  surface  temperatures.  Although  this  pulse 
is  of  short  duration,  large  portions  of  the  TPS  would  probably  be  damaged.  Still,  subsequent  conver- 
gence to  the  profile  is  quite  rapid  and  thus  the  other  constraint  margins  can  be  maintained.  Ranging 
to  the  new  landing  site  is  accomplished  in  the  normal  manner. 


FLIGHT  DECK  DISPLAYS  AND  CREW  INTERACTION 


The  flightcrew  can  monitor  entry  by  means  of  computer-driven  cathode-ray  tube  (CRT)  operations 
displays.  Figure  15  shows  the  configurations  for  the  segment  of  flight  from  a velocity  of  20  000 
ft/s  to  13  500  ft/s.  The  central  portion  of  the  display  depicts  a velocity  versus  range  plot  of  the 
entry  constraints  (solid  lines).  From  left  to  right,  these  are  2.5g  load  factor,  nominal  trajectory, 
equilibriun  glide  for  37°  bank  angle,  and  equilibrium  glide  for  0°  bank  angle.  The  dashed  lines  rep- 
resent constant-drag  levels  with  the  numerical  value  shown  above  each  line.  The  numbers  in  the  lower 
section  of  the  display  are  the  vehicle  altitude  rates  necessary  to  parallel  the  nominal  profile.  The 
square  depicts  the  current  guidance-commanded  drag  level,  and  the  Shuttle  symbol  is  the  navigation  es- 
timate of  the  vehicle  range  to  go.  The  dots  and  triangles  mark  the  past  values  of  these  quantities 
snapped  at  30-second  intervals.  In  addition,  reference  drag  command,  roll  command,  dynamic  pressure, 
and  other  guidance  and  flight  control  parameters  are  displayed  digitally.  Figure  15  represents  a sit- 
uation in  which  the  Orbiter  was  low  in  drag  and  too  far  from  the  landing  site,  but  has  converged  to 
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the  guidance  command.  In  addition  to  the  CRT's,  the  error  needles  of  both  cockpit  attitude-direction 
indicators  are  driven  by  the  guidance  outputs. 

Normally,  the  guidance  commands  are  fed  directly  into  the  flight  control  system,  but  they  can  be 
interrupted  if  the  crew  enables  the  control  stick  steering  (CSS)  mode.  In  this  configuration,  guidance 
will  continue  to  drive  the  flight  deck  displays  but  inputs  to  flight  control  are  made  by  way  of  the 
commander's  or  the  pilot's  rotational  hand  controller. 


FLIGHT  RESULTS 


Figures  12  and  13  represent  typical  flight  data  obtained  from  the  onboard  recorders  during 
entry.  No  unexpected  guidance  or  trajectory  behavior  has  been  seen  during  flight.  During  several 
entries,  manual  or  automatic  test  maneuvers  have  been  executed  for  the  purpose  of  determining  the 
Orbiter's  dynamic  and  thermal  characteri sties  more  accurately.  In  all  cases,  the  guidance  system 
reestablished  the  vehicle  on  the  proper  trajectory  in  the  predicted  amount  of  time. 


CONCLUSIONS 


The  Space  Shuttle  entry  guidance  meets  the  objectives  of  accommodating  a large  variety  of  mis- 
sion characteristics  while  maintaining  the  vehicle  within  highly  confining  physical  constraints  and 
delivering  it  to  the  target  with  the  required  accuracy.  The  guidance  logic  and  the  mission  planning 
activities  are  based  on  a reference  drag  profile  shaped  to  allow  for  flight  safety  margins.  Attitude 
commands  to  the  flight  control  system  are  provided  by  correcting  for  deviations  from  this  profile  in 
a closed-loop  manner.  The  Shuttle  flight  test  program  and  subsequent  operational  flights  have  proven 
the  soundness  of  interrelating  deorbit  targeting,  guidance,  mission  planning,  and  mission  design 
through  the  drag  acceleration  plane.  No  guidance-related  anomalies  have  occurred  during  flight,  and 
no  modifications  or  improvements  to  the  system  are  seen  as  necessary  at  this  time. 
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ABSTRACT 


An  entry  dynamic  stability  ground  test  of  the  0V102  Space  Shuttle  Orbiter  revealed  some  small 
amplitude  oscillatory  output  of  the  flight  control  system  which  could  have  constrained  flight  of  the 
STS-1  mission.  These  limit-cycle-type  outputs  were  attributed  to  a combination  of  rigid  body  mo- 
tion of  the  Orbiter  on  its  landing  gear  (not  a factor  in  flight)  and  some  interesting  effects  of  its 
digital  flight  control  system.  These  effects  included  frequency  aliasing  and  phenomena  associated 
with  digital  quantitization  of  low-amplitude  sensor  signals.  An  understanding  of  these  digital  ef- 
fects suggests  some  significant  improvements  possible  in  future  designs. 


INTRODUCTION 


The  Space  Shuttle  Orbiter  employs  a sophisticated  variable  gain,  closed-loop,  digital  flight  con- 
trol system,  designed  to  operate  over  a very  wide  range  of  flight  conditions.  A number  of  redundant 
sensors  are  used,  including  rate  gyro  assemblies  (RGA's),  accelerometer  assemblies  (AA's),  and  iner- 
tial measurement  units  (IMU's).  Data  from  these  and  other  sensors  are  processed  by  the  digital 
autopilot  (DAP)  algorithms  in  the  Shuttle's  general-purpose  computers  (GPC's).  Desired  commands  are 
then  sent  to  the  flight  control  effectors,  which  include  main  and  OMS  engine  gimbals,  elevons,  body 
flap,  speedbrake,  and  rudder.  Unlike  previous  autopilot  designs,  the  Shuttle  cannot  be  flown  open 
loop.  Even  in  manual  modes,  the  sensor-computer-effector  loop  remains  unbroken;  the  control  stick 
merely  replaces  automatic  guidance  as  one  of  the  many  inputs  to  the  control  system. 

In  designing  the  DAP  software  for  the  GPC's,  both  the  desired  effectiveness  of  the  control 
effector  in  controlling  the  Orbiter  state  and  the  undesired  effect  of  effector  motion  feeding  back 
through  the  Orbiter  structure  into  the  sensor  had  to  be  considered.  For  example,  an  abrupt  movement 
of  the  elevons  causes  a structural  vibration  which  produces  a nontrivial  feedback  from  the  rate 
gyros.  Designing  the  control  system,  then,  required  an  accurate  understanding  of  the  Orbiter's 
structural  dynamics  and  the  incorporation  of  appropriate  digital  filters  to  reduce  these  effects. 


HOT  FIRE  TEST 


Since  it  is  difficult  to  predict  the  structural  dynamics  of  a vehicle  to  a high  level  of  accu- 
racy by  analysis  only,  verifying  the  dynamic  stability  of  the  flight  control-structural  system  was  an 
obvious  candidate  for  vehicle  tests.  U.S.  Air  Force  specifications  require  automatic  flight  control 
systems  to  demonstrate  a gain  margin  of  at  least  6 decibels  during  ground  tests  (ref.  1).  A gain  mar- 
gin test  was  first  conducted  on  0V102  in  November  1979  as  part  of  the  APU  hot  fire  at  the  Kennedy 
Space  Center.  This  closed-loop  test  was  conducted  with  the  software  in  major  mode  305  (terminal  area 
energy  management  - from  Mach  = 2.5  through  rollout).  The  forward  loop  gains  were  patched  to  be  6 
decibels  higher  than  nominal,  and  pulse-type  programmed  test  inputs  were  applied.  The  result  was  a 
3.6-hertz  oscillation  in  the  roll  axis  coupled  by  the  first  fin-bending  mode  through  the  roll  rate 
gyro  into  aileron  motion  of  the  control  surfaces.  Amplitude  was  limited  by  the  control  surface  rate 
limit  in  the  software.  It  was  also  surprising  to  find  that  yaw  rate  gyros  1 and  2 were  responding  at 
6.5  hertz  and  yaw  rate  gyros  3 and  4 responding  at  3.6  hertz.  Figure  1 illustrates  these  motions. 
Figure  2 shows  the  different  mounting  locations  for  gyro  packages  1 and  2 up  on  the  fuselaqe  side 
frames.  These  side  frames  were  twisting  in  yaw  and  the  first  wing  bending  mode  frequency  (6.5  hertz) 
during  the  coupled  3.6-hertz  limit  cycle.  These  findings  resulted  in  changes  to  the  Orbiter  struc- 
tural model,  a corresponding  redesign  of  the  bending  filters  in  the  DAP  software,  and  a relocation  of 
RGA’s  1 and  2 as  shown  in  figure  2. 
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FIGURE  1.-  HOT-FIRE  TEST  DATA  (+6  dB  GAIN). 
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TABLE  1.-  EDST  FLIGHT  CONDITION  IDENTIFICATION 


FLIGHT  CONDITION 

PARAMETER 

FSSR  NAME 

CONDITION  1 

CONDITION  2 

COMMENT 

MACH 
ALT,  FT 
q,  PSF 

TAS,  FPS 
a,  DEG 
0,  DEG 

<t>,  DEG 

ac,  DEG 

MACH 

ALT 

QBAR 

REL-VEL-MAG 

TAS 

ALPHA 

THETA 

PHI 

DEFB 

3.4 

114,000 

85* 

3535 

20 

15.2 

0 

-7.7 

0.6 

41,000 

90 

581 

13.6 

1.6 
0 

•7.7 

*SET  TO  FORCE  GDQ,  GDA  TO  LIMIT  VALUE 

<*sb*  DEG 

DSBC 

5.0 

5.0 

abf«  DEG 

DBFRC 

1 

D 

0.0 

ar  DEG 

DROFB 

1 

D 

1 

D 

SIN  a 

SINALF 

.34202 

.23514 

COS  a 

COSALF 

.93969 

.97196 

SIN  0 

SINTH 

.26219 

.2792 

COS0 

COSTH 

.96502 

.99961 

SIN  <t> 

SINPHI 

( 

3 

( 

3 

COS  <t> 

COSPHI 

1.0 

1.0 

GDQ 

5.0  (MAX) 

2.06264* 

*GAIN  VALUE  EOUIV  TO  “AUTO”  WITH  CSS  OR  GAIN  ENABLE  SELECTED 

DETRIM 

DATRIM 

DRTRIM 

ROLLOUT 

FLATURN 

WOWLON 

GROUND  STEER 

( 

C 

7.7  DEG 

i 

) 

( 

( 

7.7  DEG 
) 

) 

ENTRY  DYNAMIC  STABILITY  TEST 


Because  of  this  experience,  a more  extensive  test  was  planned,  and  successful  completion  would  be 
required  before  the  STS-1  mission.  Two  flight  conditions  were  examined  (table  1).  The  first  was  in 
the  entry  mode  (major  mode  304)  with  the  DAP  patched  to  believe  it  was  at  Mach  3.4  and  an  altitude  of 
114  000  feet.  The  second  was  in  the  TAEM  mode  (major  mode  305)  with  a Mach  of  0.6  and  an  altitude  of 
41  000  feet.  For  this  entry  dynamic  stability  test  (EDST),  the  vehicle  would  be  resting  on  its  land- 
ing gear  with  the  tires  deflated.  Shop  hydraulics  would  be  used  instead  of  vehicle  auxiliary  power 
units.  A patched  version  of  the  appropriate  flight  software  would  be  loaded,  and  necessary  vehicle 
systems  would  be  powered  up.  The  KSC  launch  processing  system  would  be  used  to  uplink  flight  soft- 
ware patches,  command  step  inputs,  and  thereby  control  the  test.  Figure  3 illustrates  the  vehicle 
configuration.  The  multiplexer/demultiplexer  units  (MDM's),  in  addition  to  their  obvious  function, 
provided  the  necessary  analog-to-digital  and  digital-to-analog  conversions.  It  will  be  shown  that 
this  A-D  process  had  significant  effects  on  the  test.  The  Shuttle  modal  test  and  analysis  set  (SMTAS) 
consisted  of  special  test  equipment  used  for  sinusoidal  test  inputs,  data  collection,  and  reduction. 
Step  inputs  would  be  provided  to  excite  the  system  by  providing  torque  commands,  normally  used  only 
for  ground  checkout,  to  the  rate  gyros.  In  addition  to  the  closed-loop  test,  an  open-loop  test  was 
planned.  Here,  the  DAP  commands  to  the  actuators  were  disconnected  and  a sine  wave  substituted  in 
their  place.  This  signal  was  slowly  swept  from  frequencies  of  1 to  18  hertz,  which  allowed  measure- 
ment of  the  actual  aerosurface  command  to  sensor  to  DAP  command  transfer  functions.  This  test  would 
be  useful  in  understanding  the  closed-loop  response. 
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FIGURE  3.-  OPEN-  AND  CLOSED-LOOP  CONFIGURATIONS. 


RESULTS 

Consequently,  the  EDST  was  conducted  on  0V102  in  August  of  1982.  The  low-altitude  (MM  305)  case 
was  stable  and  well  damped  at  both  nominal  and  +6  decibel  DAP  gains.  The  high-altitude  case,  at  nomi- 
nal gains  before  any  test  stimuli  were  applied,  entered  a sustained  symmetric  elevon  oscillation  of 
about  0.6  degrees  peak-to-peak  at  2.5  hertz.  This  had  not  been  predicted  pretest,  but  since  the  am- 
plitude was  small  and  the  response  to  step  input  was  damped,  the  test  was  continued. 

When  the  gains  were  increased  +6  decibels,  an  antisymmetric  elevon  oscillation  of  3 degrees 
peak-to-peak  at  2.5  hertz  were  encountered,  again  before  any  test  stimuli  were  applied.  This  oscilla- 
tion was  a limit  cycle,  signifying  that  the  elevon  motion  had  reached  the  rate  limit  applied  for 
hydraulic/mechanical  considerations.  To  complete  the  test,  the  gains  were  backed  down  to  +3  decibels 
above  nominal  in  the  roll  and  yaw  channels,  while  being  kept  at  +6  decibels  in  pitch.  Here  the  oscil- 
lations continued  but  were  symmetric,  and  the  amplitude  was  limited  to  about  1 degree,  less  than  the 
limit  cycle.  The  response  to  step  inputs  was  damped. 


DISCUSSION 

The  results  of  this  test  caused  concern  about  their  potential  impact  to  the  STS-1  mission.  Were 
these  effects  liable  to  appear  in  flight?  Were  they  acceptable?  If  a significant  redesign  of  the 
flight  system  were  required,  it  would  cause  a very  substantial  impact  to  the  whole  STS  schedule. 

These  oscillations  were  attributed  to  two  causes:  (1)  the  interaction  of  the  Orbiter  with  its  suspen- 

sion system  (landing  gear)  and  (2)  a combination  of  effects  unique  to  digital  systems. 
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FIGURE  4.-  PSA  3 ROLL  TRANSFER  FUNCTION  PLOT 
SWEEP  2-1  - AILERON  ROLL. 


The  open-loop  tests  showed  that  the  lower-frequency  structural  modes  agreed  very  well  with  the 
models,  but  at  higher  frequencies  they  were  much  more  heavily  damped  than  had  been  predicted.  The 
tests  also  showed  that  the  rigid  body  mode  of  the  Orbiter  on  its  landing  gear  had  a higher  than 
predicted  natural  frequency,  and,  in  the  roll  channel,  a much  higher  than  predicted  frequency  re- 
sponse. Figure  4 shows  the  predicted  versus  actual  frequency  response  in  the  roll  channel.  This  fig- 
ure is  a composite  made  from  two  frequency  sweeps:  one  from  1 to  2 hertz,  the  other  from  2 to  12.5 

hertz.  The  second  peak  after  2 hertz  is  probably  a start-up  transient  response  reflecting  the  1.9- 
hertz  landing  gear  mode.  This  higher-than-predicted  rigid  body  mode  was  the  proximate  cause  for  the 
+6  decibel  antisymmetric  instability.  But  why  was  this  instability  at  2.5  hertz  instead  of  the  1.9- 
hertz  rigid  body  mode?  What  caused  the  lower  amplitude  symmetric  motion  at  the  lower  gains?  For 
this,  some  digital  effects  which  provided  the  real  "lessons  learned"  should  be  examined. 

These  digital  effects  were  the  phenomena  of  frequency  aliasing  and  the  effects  of  digital 
quantization  of  small  amplitude  signals.  Frequency  aliasing  is  caused  by  the  fact  that  a digital 
system  can  sense  a signal  only  at  discrete  time  intervals.  The  sampling  theorem  requires  that  the 
frequency  of  the  signal  being  measured  be  no  greater  than  one-half  of  the  frequency  of  the  sampling 
itself.  The  Orbiter's  RGA's  are  sampled  at  25  hertz.  Thus,  the  highest  frequency  input  which  could 
be  effectively  handled  (or  Nyquist  rate)  is  12.5  hertz.  Signals  higher  than  this  are  "folded  over" 
around  the  Nyquist  rate  to  a lower  frequency.  For  example,  a 23-hertz  signal  would  reflect  around 
12.5  hertz  to  appear  as  a 2-hertz  signal  to  the  flight  system.  Figure  5 helps  to  provide  an  intui- 
tive appreciation  of  the  effect.  In  theory,  high-frequency  structural  modes  could  be  reflected  down 
to  appear  to  the  DAP  as  low-frequency  inputs,  effectively  circumventing  the  digital  filters  designed 
to  attentuate  them.  Because  of  this  concern,  open-loop  frequency  sweeps  were  made  during  the  EDST  up 
to  frequencies  of  18  hertz.  However,  these  sweeps  showed  that  the  high-frequency  structural  modes 
were  much  more  heavily  damped  than  predicted  and  should  not  have  been  important.  Aliasing  was  impor- 
tant, however,  but  only  as  it  was  associated  with  some  small  amplitude  signal  quantization  effects. 

The  stair  steps  in  figure  6 represent  the  way  an  analog  signal  from  an  RGA  is  quantitized  into 
a digital  signal  in  the  Shuttle  MDM.  For  normal  large  amplitude  signals,  the  steps  are  relatively 
small  enough  to  represent  a straight  line  with  a gain  of  unity.  However,  as  the  relative  size  of  the 
signal  decreases,  the  effective  gain  can  increase  dramatically.  The  small  signal  shown  is  engaging 
one  quantization  step,  and  it  is  obvious  that  its  gain  could  increase  to  a very  high  number,  depen- 
dent on  the  bias  and  amplitude  of  the  input.  The  output  from  this  system  would  be  a bit  toggling 
square  wave.  Figure  7 illustrates  the  way  a square  wave  can  be  represented  in  terms  of  its  Fourier 
components.  Consider  a 7.5-hertz  square  wave.  Its  primary  Fourier  component  would  be  well  atten- 
uated by  the  DAP  bending  filter.  However,  its  third  Fourier  harmonic  would  be  22.5  hertz,  which 
would  alias  to  2.5  hertz.  It  is  also  interesting  that  the  third  harmonic  of  2.5  hertz  is  the  origi- 
nal 7.5  hertz,  thus  making  it  possible  for  the  signal  to  feed  itself.  In  fact,  there  is  a family  of 
frequencies  which  have  harmonics  capable  of  aliasing  in  such  a way  as  to  reinforce  themselves  as 
shown  in  table  2.  Factors  which  limit  their  actual  impact  are  the  DAP  bending  filters  and  the  fact 
that  for  a square  wave,  the  amplitude  of  the  harmonic  component  is  inversely  proportional  to  its 
order. 

These  effects  can  be  seen  in  some  data  taken  during  the  open-loop  test.  Figure  8 is  actual  data 
taken  during  a frequency  sweep.  The  first  three  channels  are  RGA  inputs  to  the  DAP.  The  last  chan- 
nel is  a DAP  elevon  command,  which  was  disconnected  from  the  actuators  to  open  the  loop.  On  the  left 
side,  the  elevons  are  being  driven  at  about  7.5  hertz  with  the  frequency  slowly ■ increasing  with  time. 
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FIGURE  5.-  SAMPLING/HOLO  CHARACTERISTICS  (ALIASING). 


FIGURE  6.-  MDM  QUANTITIZATION  EFFECTS. 
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TABLE  2.-  TWENTY-FIVE-HERTZ  SAMPLING  CHARACTERISTICS 


FUNDAMENTAL 

FREQUENCY 

3RD  HARMONIC 
FREQUENCY 

ALIASED 

FREQUENCY 

3RD  HARMONIC  CHARACTERISTICS 

6.25 

18.75 

6.25 

12.50 

37.5 

12.5 

(3RD  HARMONIC)^  CHARACTERISTICS 

2.5 

7.5 

22.5 

2.5 

3.125 

9.375 

28.125 

3.125 

5TH  HARMONIC  CHARACTERISTICS 

4.167 

20.833 

4.167 

6.25 

31.25 

6.25 

(5TH  HARMONIC)^  CHARACTERISTICS 

0.9615 

4.8077 

24.038 

0.9615 

1.0416 

5.2083 

26.0416 

1.0416 

7TH  HARMONIC  CHARACTERISTICS 

3.125 

21.875 

3.125 

4.167 

29.167 

4.167 

(7TH  HARMONIC)^  CHARACTERISTICS 

0.50 

3.50 

24.50 

0.50 

.5208 

3.646 

25.5208 

.5208 
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FIGURE  8.-  DAP  FILTER  RESPONSE  TO  TOGGLING  INPUT 


The  RGA's  are  mostly  toggling  1 bit  producing  the  small  square  waves  discussed,  only  occasional- 
ly engaging  a second  quantization  level.  Now  observe  the  DAP  command,  a very  significant  sine  wave 
with  a frequency  of  about  2.5  hertz. 

In  looking  at  this  type  of  data,  other  cases  showed  significant  aliased  harmonics  in  the  output 
although  they  did  not  feed  themselves  and  thus  did  not  contribute  to  oscillatory  behavior.  The  key 
here  seemed  to  be  whether  or  not  the  sampled,  aliased  harmonic  had  a period  which  was  an  integral  mul- 
tiple of  the  sampling  period.  Those  which  did  could  be  expressed  "cleanly"  by  the  digital  system. 
Those  which  did  not  experienced  frequent  phase  shifts  as  the  signal  "beat"  against  the  sample  rate 
and  quickly  lost  their  significance.  Table  3 shows  the  harmonics  greater  than  1.5  hertz,  which  meet 
this  criterion  for  a 25-hertz  sampling  system  and  the  inputs  necessary  to  create  them. 

The  driving  signals  greater  than  10  hertz  appear  to  be  aliasing  second  harmonics  which  would  in- 
validate our  odd-only  rule  derived  from  the  Fourier  components  of  a square  wave.  Actually,  these  are 
fifth  and  seventh  harmonics  aliased  around  50  to  75  hertz.  The  cases  where  this  effect  would  be  im- 
portant would  be  where  an  open-loop  "noise"  source  existed;  e.g.,  an  ac  signal  in  an  RGA  which  might 
alias  to  manifest  itself  in  unexpected  places. 

As  stated,  only  a few  of  these  frequencies  can  feed  back  to  reinforce  themselves,  and  some  of 
these  are  attenuated  by  the  bending  filter.  Let's  consider  another  effect  of  the  bending  filter. 
Figure  9 shows  three  plots.  The  first  plot  (a)  is  the  frequency  response  of  a zero  order  hold 
(sample  and  hold)  with  a sample  rate  of  25  hertz.  The  second  plot  (b)  shows  the  frequency  response 
of  the  Shuttle  pitch  channel  bending  filter.  The  curve  between  20  and  30  hertz  is  obtained  by 
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TABLE  3.  - VULNERABLE  FREQUENCIES  IN  TWENTY" FIVE-HERTZ  SYSTEM, 


FREQUENCY  OF 
ALIASED  HARMONIC,  Hz 

FREQUENCY  OF  DRIVING 
SIGNALS 

5 

10 

3.5714 

10.714 

7.1429 

3.125 

9.375 

2.7778 

11.1111 

5.5556 

2.5 

7.5 

2.2727 

11.3636 

9.0909 

6.8182 

4.5455 

1.9231 

11.538 

7.6923 

5.7692 

3.8462 

1.7857 

8.9286 

5.357 

1.6667 

11.667 

6.6667 

3.3333 

1.5625 

7.8125 

4.6875 

reflecting  the  bending  filter  curve  around  25  hertz  and  scaling  it  by  the  frequency  response  of  the 
zero  order  hold.  The  third  plot  (c)  shows  this  20  to  30-hertz  region  increased  +6  decibel.  Notice 
how  perfectly  the  filter  tunes  to  22.5  and  27.5  hertz  which,  of  course,  alias  to  2.5  hertz. 

Figure  10  gives  a good  overview  of  the  system  with  the  effects  discussed.  It  can  be  seen  why 
the  2.5-hertz  phenomena  were  encountered.  The  pressing  question  after  the  DST  was  whether  or  not  it 
was  safe  to  fly.  The  landing  gear  mode,  of  course,  would  not  be  a factor  in  flight.  For  landing  and 
rollout,  the  DAP  would  be  in  the  low-altitude  flight  condition,  which  was  found  to  be  quite  stable. 
What  about  the  digital  effects?  Could  they  lead  to  large  instabilities?  The  answer  is  no  because 
they  are  bounded  to  small  amplitude.  Considering  figure  6,  it  is  obvious  that  as  the  input  signal  in- 
creases to  engage  more  quantitization  steps,  its  gain  rapidly  decreases  to  approach  unity.  Or,  using 
the  Fourier  approach,  the  more  quantitization  steps  a signal  engages,  the  more  it  resembles  a sine 
wave  and  the  weaker  its  harmonics  become.  After  the  DST,  these  effects  were  modeled  in  a time  domain 
simulation.  The  results  are  shown  in  figures  11  and  12.  It  is  obvious  that  while  the  effects  are 
significant  at  low  amplitudes,  as  either  the  amplitude  is  increased  or  the  quantitization  level  is 
reduced,  they  rapidly  become  less  important. 


CONCLUDING  REMARKS 


So  the  Shuttle  is  safe  to  fly.  What  can  be  learned  from  this  experience  that  can  be  applied  to 
future  projects?  First,  this  stresses  the  importance  of  a high  sample  rate.  Increasing  this  rate, 
in  addition  to  eliminating  many  other  undesirable  effects,  reduces  the  number  of  significant  har- 
monics which  can  be  aliased.  Second,  the  size  of  any  analog  to  digital  quantitization  levels  should 
be  carefully  considered  in  view  of  the  application.  In  the  case  examined,  the  quantitization  was 
quite  appropriate  for  low-altitude  flight.  But  it  became  inappropriate  with  the  control  system  gains 
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AMPLITUDE  RATIO 


ZERO  ORDER 
HOLD 


SHUTTLE  BENDING 
FILTER 

(NOMINAL  GAINS) 


(b)  SHUTTLE  BENDING  FILTER 
(NOMINAL  GAINS). 


SHUTTLE  BENDING 
FILTER 

(+6dB  GAINS) 


(c)  SHUTTLE  BENDING  FILTER 
(+6  dB  GAINS). 


FIGURE  9.-  BENDING  FILTER  FREQUENCY  RESPONSE. 


required  for  flight  at  high  altitude  and  Mach  number.  It  may  be  worthwhile  to  study  some  new  ap- 
proaches, such  as  variable  quantization  levels,  as  illustrated  in  figure  13.  This  would  provide 
higher  resolution  around  a trim  point  than  could  be  provided  over  the  whole  range.  In  some  cases, 
the  best  approach  might  be  a hybrid  system  with  completely  analog  inner  loops  and  digitally-controlled 

?ains.  Finally,  the  software  control  laws  should  be  designed  with  an  appreciation  of  these  effects, 
here  was  no  hard  reason  for  the  Shuttle  bending  filter  to  peak  at  2.5  hertz  or  to  have  such  a pro- 
nounced peak  at  all.  It  was  merely  tolerated,  with  no  appreciation  of  the  consequences,  to  gain 
a marginally  better  band  pass.  As  future  control  systems  evolve,  an  understanding  of  these  digi- 
tal effects  will  be  important  for  achieving  optimal  designs. 
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FIGURE  IQ.-  FLIGHT  CONTROL  SYSTEM  ( FLEXIBLE-MODE-RELATED  CONFIGURATION). 
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FIGURE  11.-  VARIATION  OF  GYRO  OUTPUT  AMPLITUDE. 
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FIGURE  12.-  VARIATION  OF  MDM  QUANTITIZATION  LEVEL. 
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SPACE  SHUTTLE  HANDLING  QUALITIES 


David  W.  Gilbert 

NASA  Lyndon  B.  Johnson  Space  Center 
Houston,  Texas 


ABSTRACT 


This  paper  provides  an  overview  of  the  initial  Orbiter  handling  qualities  requirements,  their  ef- 
fect on  the  vehicle  design,  and  how  it  all  turned  out  through  the  first  six  orbital  missions.  Follow- 
ing this,  there  is  a series  of  more  detailed  discussions  of  some  specific  areas  consisting  of  hand 
controller  considerations  and  the  wheelie  problem.  Finally,  there  is  a discussion  which  reviews  the 
requirements  for  the  pitch  axis  subsonic  flight  control  system  and  provides  some  results  of  recent 
simulator  evaluations  to  compare  the  existing  system  at  landing  with  several  other  configurations. 


THE  REQUIREMENTS 

The  original  handling  qualities  requirements  for  the  Space  Shuttle  were  written  more  than  10 
years  ago.  At  the  time,  the  magnitude  of  the  task  seemed  overwhelming  considering  the  size  of  the 
flight  envelope  the  variety  of  control  devices,  control  modes  and  control  tasks.  The  existing  MIL 
Spec,  and  user's  guide  run  about  800  pages.  This  provides  the  requirements  for  conventional  aero- 
dynamic vehicles  which  correspond  to  a small  part  of  the  Shuttle  mission/flight  control  matrix. 

Table  1 attempts  to  illustrate  this.  From  a flight  envelope  viewpoint,  most  conventional  aircraft  ex- 
perience lies  in  the  lower  right  corner  of  the  entry/  aerosurface  control  element  in  table  1.  What 
were  we  to  do  with  the  rest  of  it?  As  a starting  point,  the  Space  Shuttle  Flying  Qualities  Symposium 
was  held  at  what  was  then  the  Manned  Spacecraft  Center  in  Houston,  Texas  in  January  1971. * This  was 
organized  by  Donald  C.  Cheatham  (NASA,  retired)  to  solicit  industry-wide  opinion  on  the  subject.  It 
was  well  attended  by  a cross-section  of  the  guidance,  navigation,  and  control  (GN&C)  community.  The 
coverage,  however,  turned  out  to  be  limited  to  aerodynamic  control  of  entry  through  landing.  While 
most  of  the  problem  areas  were  recognized  and  discussed  and  systems  concepts  were  presented,  little 
design  criteria  was  proposed  except  in  the  approach  and  landing  area.  In  fact,  one  of  the  partici- 
pants proposed  that  definitive  criteria  were  not  needed.  Supposedly,  the  contractors  knew  what  was 
good  and  bad.  The  simple  statement  "make  it  good"  was  the  only  requirement  needed--an  interesting 
concept.  However,  the  flight  control  system  designers  said  they  needed  some  response  criteria  be- 
cause of  the  closed-loop,  fly-by-wire  control  concept  and  the  unconventional  airframe  characteristics. 
After  about  six  months  of  debate,  all  relevant  information  on  handling  qualities  for  the  whole  Shuttle 
mission  were  Incorporated  into  30  pages  of  text. 

The  basic  reason  for  the  relatively  abbreviated  set  of  requirements  was  that  It  was  not  Intended 
to  be  a generally  applicable  specification  for  manned  spacecraft  or  define  the  total  boundary  of  ac- 
ceptable conditions  and  the  ultimate  limits  between  acceptable  and  unacceptable.  Instead,  it  was  In- 
tended to  present  conditions  that  were  thought  to  be  easily  achievable  and  fall  well  within  the  ac- 
ceptable boundaries  for  a specific  vehicle  and  mission  concept.  No  theoretical  rationale  was  pro- 
vided. The  requirements  were  based  on  simulations  of  the  vehicle  and  mission  as  known  at  the  time. 

One  underlying  assumption  was  that  there  would  always  be  active,  closed-loop  control  of  vehicle  re- 
sponse parameters  with  sufficient  control  power  and  parameter  adjustment  capability  to  get  any  type 
of  response  desired.  In  most  cases,  all  that  was  specified  was  the  control  power  or  maneuver  rate, 
the  control  modes,  and  a transient  response  envelope.  The  response  requirement  format  chosen  allowed 
the  requirements  for  the  whole  mission  to  be  specified  on  two  pages.  It  was  all  quite  arbitrary. 
However  it  represented  something  that  worked  on  the  existing  simulators  and  was  consistent  with 
Apollo  experience  where  it  was  considered  applicable. 

The  remote  manipulator  system  is  shown  as  a control  effector  used  during  onorbit  payload  opera- 
tions. This  was  not  addressed  in  the  original  requirements,  as  it  is  in  a slightly  different  class. 
Because  of  the  flexibility  of  the  arm,  the  limited  force,  and  variable  geometry  and  inertia  it  is 
not  a trivial  matter.  It  is  a valid  man-in-the-loop  handling  qualities  consideration  for  payload 
operations,  especially  heavy  payloads.  Handling  qualities  had  no  significant  influence  on  the  de- 
sign other  than  control  mode  and  controller  configuration.  The  task  now  Is  to  accommodate  the  result. 

To  provide  Shuttle-type  vehicles  with  conventional  handling  qualities  requirements  during  as- 
cent, onorbit,  and  early  entry  is  a very  big  job  remaining  to  be  done.  One  might  debate  whether  it 
really  needs  doing.  The  need  to  compromise  with  the  ideal  handling  qualities  requirements  will  be 
much  greater  for  this  type  of  vehicle  because  of  the  potential  costly  impact  on  vehicle  configuration 
and  consumables.  As  a result,  the  need  to  define  the  minimum  acceptable  side  of  the  requirement  is 
probably  where  the  real  urgency  lies. 
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TABLE  I 


Mission  phase 

Control  effectors 

Launch  and  Abort 

Onorbit 

Entry 

SRB/M.E.  - TVC 

First  stage  ascent 
Attitude  control 
Fly  commands 

M.E.  TVC  Guided  ascent  and 

Abort  - fly  the 
Commands 

RTLS,  TAL,  AO A,  ATO 


OMS  TVC 


Orbit  insertion  AV 
Fly  commands 


Orbit  maneuver  AV 

Rendezvous 

Deorbit 


RCS 

Single  engine  OMS 
Roll  control 
Fly  commands 

Attitude  control 
Stationkeep 
Prox  OPS 
Payload  OPS 
Single  engine  OMS 
Roll  control 

q < 2 PSF 
Fly  commands 

RCS/AERO 

q = 2 PSF  - M = 1 
Fly  commands 

Aero  Surfaces 

Trim  for  load  relief 

M < 1 

Fly  commands  > OTW 

RMS 

Payload  OPS 

RESULTS 


After  five  approach  and  landing  test  flights  and  six  orbital  missions,  a major  result  is  that 
the  only  significant  handling  quality  concerns  have  been  in  that  little  area  where  we  have  vast  expe- 
rience— the  landing  maneuver— specif ically,  the  final  flare  to  touchdown  and  the  derotation  to  lower 
the  nose  gear.  In  reviewing  this  ironic  turn  of  events,  it  appears  that  the  reason  is  that  in  de- 
signing a vehicle  that  performs  well  in  all  the  other  mission  phases  where  we  have  less  experience, 
we  have  so  changed  the  inherent  vehicle  characteristics,  the  flight  control  system  and  the  flight 
path  that  it  is  no  longer  representative  of  the  experience  we  do  have.  Efforts  to  make  it  more  con- 
ventional for  landing  failed  due  to  the  penalties  in  weight,  performance,  and  complexity  imposed  on 
some  other  part  of  the  mission.  The  factors  we  were  driven  to  accept  were  the  following: 


1. 

Unpowered  approach  and  landing 

5. 

Lack  canard  control  surfaces 

2. 

Lack  of  static  stability 

6. 

High  landing  speed 

3. 

Elevon  controls 

7. 

Massive  redundancy 

4. 

Lack  of  direct  lift  control 

8. 

Digital  flight  control 

These  factors  either  by  themselves  or  combined  affect  the  handling  qualities  during  approach  and 
landing.  The  last  two  contribute  to  additional  time  delays  in  the  flight  control  system. 
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From  an  overall  standpoint,  handling  qualities  did  not  have  much  effect  in  determining  the  con- 
figuration of  a really  new  first-generation  vehicle,  such  as  the  Orbiter.  Some  of  the  reasons  for 
this  are  the  following: 

1.  In  a radically  new  first-generation  vehicle,  the  uncertainties  in  performance  and  survival 
far  overshadow  the  vagaries  of  handling  qualities  requirements.  In  terms  of  urgency,  compromises  are 
not  likely  to  be  made  in  favor  of  handling  qualities.  In  a second -generation  vehicle,  the  result 
might  be  quite  different  since  both  handling  qualities  and  performance  capability  would  be  better  un- 
derstood. 

2.  With  the  advent  of  fly-by-wire  and  digital  flight  control,  there  is  a tendency  to  assume 

that  any  handling  qualities  problem  can  be  solved  with  software.  There  is  probably  even  a lot  of 

truth  in  that  but  it  does  not  follow  that  we  are  instantly  smart  enough  to  know  how  to  do  it.  We 

still  have  a lot  to  learn  about  the  fine  points  of  fly-by-wire,  closed-loop  control  of  statically  un- 
stable aircraft  in  situations  where  precise  control  relative  to  another  near  object  (a  vehicle  or  the 

ground)  is  concerned.  Even  with  a more  favorable  vehicle  configuration,  it  would  be  easy  to  end  up 
with  poor  handling  qualities  due  to  the  way  the  control  loops  are  designed.  There  are  a lot  more 
choices  but  we  do  not  understand  the  additional  set  of  limitations  that  go  with  them.  There  are  more 
ways  to  go  wrong.  The  trend  in  vehicle  design,  however,  seems  clearly  to  optimize  for  performance 
and  depend  more  on  fully  active  computer  dependent  flight  control  systems  to  make  up  the  deficien- 
cies. The  Orbiter  took  a giant  step  in  that  direction. 

3.  These  are  interesting  and  challenging  problems— the  kind  that  engineers  like  to  work  on. 
Sometimes  we  are  too  willing  to  accept  the  challenge  rather  than  argue  for  the  tried  and  true.  So, 
in  a sense,  we  tend  to  invite  trouble. 

4.  Finally,  there  is  the  fallback  argument  that  if  handling  qualities  become  too  much  of  a prob- 
lem, the  auto  mode  is  always  available.  However,  the  auto  mode  must  be  given  equal  priority  in  the 
design  process  as  it  was  in  the  Shuttle.  Each  control  mode  has  its  unique  problems.  For  a really 
new  vehicle,  providing  both  greatly  improves  the  likelihood  that  at  least  one  will  always  be  avail- 
able. 

The  reason  there  have  not  been  more  problems  in  other  mission  phases  might  be  that  so  far  they 
have  not  really  been  exercised  in  situations  that  are  critical  from  a handling  qualities  standpoint. 
All  launches  have  been  in  automatic  control  with  no  launch  aborts.  We  have  not  done  any  rendezvous, 
stationkeeping,  or  docking  yet.  It  is  the  operation  in  close  proximity  to  another  object  that  tends 
to  stress  the  handling  qualities.  For  the  most  part,  however,  onorbit  operations  are  not  time  criti- 
cal and  proceed  very  slowly.  Some  can  even  accommodate  repeated  attempts;  e.g.,  docking.  So  there 
really  is  no  reason  for  concern  at  this  time. 

During  most  of  entry,  maneuver  rates  are  very  low.  Most  have  been  flown  in  the  auto  mode.  How- 
ever, enough  has  been  done  to  indicate  the  pilot  has  adequate  control  to  perform  the  required  bank  re- 
versals manually  and  has  done  some  pushover /pul  1 -up  maneuvers  to  gather  aero  data.  The  significant 
issue  here  appears  to  be  RCS  propellant  consumption  not  handling  qualities.  The  auto  system  tends  to 
use  less.  The  anomalies  that  did  occur  are  the  result  of  variations  in  the  aero  data  from  that  used 
to  design  the  system  and  affects  both  auto  and  manual  modes. 

Subsonically,  the  pilot  appears  to  have  no  problem  flying  the  vehicle  manually  to  perform  the 
heading  alignment  maneuvers,  the  steep  approach  and  preflare.  From  there  to  touchdown,  it  appears 
necessary  to  exercise  unusual  care  to  avoid  large  control  inputs  which  tend  to  produce  pilot-induced 
oscillation  (PIO)  in  the  pitch  axis.  More  about  that  later.  One  other  exception  is  the  effect  of 
winds  aloft.  Since  the  Orbiter  is  unpowered,  its  trajectory  and  energy  management  can  be  greatly 
affected.  In  three  of  the  first  six  missions,  there  have  been  winds  outside  of  the  environmental  de- 
sign specification.  Some  last-minute  modifications  to  the  approach  trajectory  were  required.  There 
has  been  a continuing  effort  to  develop  ways  to  make  the  system  able  to  accommodate  a wider  range  of 
wind  conditions. 


SOME  PROBLEMS  AND  CONCERNS 

Several  other  topics  warrant  some  further  discussion  with  respect  to  handling  qualities.  These 
are  hand  controller  configuration,  the  derotation  control  problem  or  "wheelie",  and  the  pitch  axis 
flight  control  system  tendency  toward  pilot  induced  oscillation  at  landing.  This  section  will  ad- 
dress each  of  these. 
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HAND  CONTROLLER  CONCERNS 


The  Orbiter  uses  the  same  Apollo-type  hand  controller  for  both  aero  control  and  onorbit  reaction 
control  system  (RCS)  attitude  control.  The  latter  is  essentially  an  on/off  control  function.  Ide- 
ally it  should  have  a different  type  of  feel  than  that  required  for  good  aero  control.  We  optimized 
as  much  as  possible  for  good  aero  control  and  accepted  the  result  for  RCS  control.  As  a result,  it 
is  impossible  to  tell  by  the  feel  force  exactly  when  the  jets  fired.  Consequently,  there  is  a ten- 
dency to  make  sure  the  control  input  is  big  enough.  There  has  been  some  concern,  but  this  is  appar- 
ently acceptable,  although  some  of  the  more  demanding  tasks  like  docking  have  not  been  done  yet.  The 
alternative  is  more  mechanical  complexity,  such  as  having  two  controllers  or  adjustable  feel.  Al- 
though this  area  could  be  developed  further,  it  doesn't  appear  necessary. 

Another  peculiarity  of  this  most  simple  fly-by-wire  hand  controller  is  the  aero  trim  function. 

In  a conventional  mechanical  system,  the  stick  force  can  be  trimmed  without  moving  the  stick.  In  the 
Orbiter,  the  manual  trim  signal  goes  into  the  control  loop.  This  causes  the  vehicle  to  respond  un- 
less one  backs  off  on  the  controller  as  the  trim  is  applied.  In  general,  this  cannot  be  done  perfect- 
ly but  there  have  been  no  complaints.  This  is  probably  because  the  manual  trim  is  hardly  ever  used 
since  automatic  trim  follow-up  is  available.  It  would  complicate  the  controller  greatly  to  make  the 
trim  function  appear  conventional. 

Controller  location  was  also  of  some  concern.  It  is  in  the  center  (not  side  stick)  and  canted 
some  19  degrees  left  to  be  comfortable  for  right-hand  use.  It  provides  better  access  and  room  for 
displays  and  switches.  However,  there  was  concern  about  the  possibility  of  control  cross-coupling 
since  it  is  not  aligned  mechanically  with  the  vehicle  axes.  To  keep  it  in  the  center  and  aligned 
with  vehicle  axes  would  make  it  misaligned  with  natural  arm  motion.  Either  way  some  cross-coupling 
is  likely.  It  does  occur  at  times  but  not  to  a large  degree  and  apparently  has  not  been  objection- 
able. 


In  the  Orbiter,  the  hand  controller  is  only  connected  to  some  electrical  transducers  and  feel 
springs.  It  is  easy  to  move  the  controller  faster  than  the  surface  can  respond  without  knowing  it. 
When  this  happens  in  one  control  axis,  a small  input  in  the  other  axis  will  be  ignored  in  an  elevon 
system  unless  some  special  limiting  is  provided  in  the  software.  We  did  not  have  this  limiting  ini- 
tially because  it  did  not  appear  that  the  problem  ever  arose  during  simulations.  During  the  last 
approach  and  landing  test  (ALT)  flight  however  the  situation  occurred.  Small  lateral  inputs  were 
ignored  until  the  pilot  put  in  a big  one  provoking  a lateral  PIO  when  the  vehicle  suddenly  responded. 
We  subsequently  added  a series  of  limiters  in  the  aileron/elevator/elevon  mixer  logic.  This  insured 
that  control  in  one  axis  was  never  completely  locked  out  due  to  rate  saturation  in  the  other. 

This  resulted  in  getting  by  with  a very  simple  and  light-weight  hand  controller  configuration 
relative  to  what  it  might  have  been. 


THE  "WHEELIE" 

The  wheelie  that  occurred  on  STS-3  was  a bonafide  handling  qualities  problem  even  though  it 
occurred  after  main  gear  touchdown.  The  external  symptom  was  the  unintended  pitch  up  during  rollout 
after  the  nose  had  started  down.  The  problem  is  caused  by  the  change  in  geometry  that  takes  place 
when  the  vehicle  touches  down.  The  center  of  rotation  shifts  from  the  center  of  gravity  to  the  main 
gear.  This  aft  shift  in  the  center  of  rotation,  coupled  with  a vehicle  that  is  already  statically  un- 
stable, results  in  a rapidly  increasing  nose  down  moment  as  the  nose  is  lowered.  The  control  system 
configured  for  the  inflight  situation  could  not  keep  up  with  the  rapidly  changing  elevator  trim  re- 
quirement. Nor  could  it  provide  a stable  pitch  rate  control  loop.  This  was  recognized  analytically 
early  in  the  program.  However  there  was  a reluctance  to  accept  the  required  switching  of  control  sys- 
tem parameters  at  touchdown  that  is  necessary  to  compensate  for  the  change  in  geometry.  Instead,  the 
pilots  demonstrated  during  simulations  that  they  could  handle  the  problem.  The  procedure  was  to  hold 
the  nose  up  at  the  touchdown  attitude  until  the  speed  decreased  to  an  acceptable  value.  Then  the 
nose  gear  is  let  down.  Pitching  over  can  cause  full-up  elevator  and  if  started  at  too  high  an  air- 
speed can  result  in  excessive  gear  loads.  Once  the  nose  starts  down,  the  trim  changes  so  fast  that 
is  is  almost  impossible  to  stop  it  without  overcontrolling.  That's  what  happened  on  STS-3.  It  was 
not  too  difficult  for  the  lightweight  ALT  Orbiter.  However,  at  today's  heavier  landing  weight  and  es- 
pecially combined  with  a forward  center  of  gravity,  the  control  task  is  considered  unacceptable. 

The  problem  was  reevaluated  on  a fixed  base  simulator  and  several  fixes  were  developed.  They 
involved  changing  the  flight  control  system  for  landing  or  switching  parameters  at  touchdown.  Fortu- 
nately, this  problem  was  quite  obvious  on  the  simulator  and  it  was  also  quite  noticeable  when  an  im- 
provement was  made.  The  simulator  evaluation  included  a sequence  where  the  nose  was  lowered  then 
raised  again  to  evaluate  controllability  under  the  worst  weight  and  center  of  gravity  conditions.  We 
ended  up  choosing  the  fix  that  was  simplest  to  implement.  This  consisted  of  switching  the  pitch  axis 
hand  controller  output  through  the  same  signal  path  that  the  autoland  system  uses.  It  switches  param- 
eters at  touchdown.  Most  of  the  software  was  already  there. 
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LANDING  FLIGHT  CONTROL 


The  Orbiter  pitch  axis  control  during  landing  has  undoubtedly  been  the  single  most  worrisome 
handling  qualities  problem.  The  symptoms  are  that  if  the  pilot  attempts  to  take  very  aggressive  con- 
trol of  the  vehicle  close  to  the  ground  and  force  it  to  land  at  a specific  point,  there  is  a tendency 
to  get  into  a pilot-induced  oscillation.  As  a result,  the  pilots  have  learned  to  get  the  approach 
well  set  up  early  from  an  energy  standpoint  and  take  unusual  care  to  avoid  large  inputs  close  to  the 
ground.  Gusts  and  crosswinds  could  aggravate  this  technique,  hence,  the  concern. 

The  attitude  control  response  has  been  consistently  reported  as  crisp.  Consequently  there  is 
something  deficient  in  the  path  control;  i.e.,  the  control  of  altitude  rate  or  normal  acceleration. 
This  always  leads  back  to  the  same  dilemna.  It  is  obvious  that  the  normal  acceleration  (Nz)  response 
is  sluggish.  To  quicken  it  significantly  requires  more  overshoot  in  the  pitch #rate  response  and  the 
pilots  always  object  to  that.  Notice  that  the  choice  of  feedback  parameters  (0  or  Nz)  is  not  neces- 
sarily a significant  issue  here.  The  response  to  command  can  be  made  the  same  with  either  feedback 
depending  on  how  it  is  shaped.  But  either  way,  to  get  faster  Nz  response  means  more  pitch  rate  over- 
shoot. Actually,  pitch  rate  was  selected  as  the  specified  response  parameter.  It  was  well  behaved 
with  no  initial  reversals  or  dependence  on  sensor  location  as  is  the  case  for  Nz.  This  does  not 
inherently  limit  any  type  of  control  system  configuration  but  just  judges  them  based  on  the  pitch 
rate  response.  Other  considerations  for  choice  of  feedback  parameter  in  the  actual  system  are  based 
on  the  response  to  external  disturbance.  For  a vehicle,  such  as  the  Orbiter,  with  zero  or  slightly 
negative  static  stability,  pitch  rate  appears  the  safer  choice.  It  is  less  demanding  on  surface  rate 
in  gusts  and  turbulence.  To  rate  limit  under  these  conditions  could  mean  loss  of  control. 

More  analytical  treatments  in  references  3 and  4 have  pointed  out  that  the  existing  pitch  rate 
control  system  mechanization  cancels  the  inherent  zeros  in  the  bare  airframe  pitch  rate  transfer  func- 
tion and  replaces  them  with  another  term  that  does  not  completely  cancel  the  corresponding  term  in 
the  flight  path  response  like  a conventional  unaugmented  airframe.  Figure  1 illustrates  this.  The 
result  shown  in  figure  2 is  an  unnatural  attentuation.  There  is  also  an  additional  phase  lag  in  the 
flight  path  response  relative  to  what  it  would  be  with  perfect  cancelation.  There  are,  in  general, 
two  ways  to  correct  this.  One  is  to  reshape  the  pitch  rate  control  system  to  preserve  the  bare 
airframe  short  period  zero  as  in  reference  4.  The  other  way  is  to  add  a lead/lag  filter  in  the  hand 
controller  output.  It  is  tuned  to  cancel  the  existing  system  zero  and  replace  it  with  the  natural 
airframe  value.  Since  this  is  done  outside  the  control  loop,  it  does  not  change  the  stability  mar- 
gins of  the  inner  control  loop.  It  only  changes  the  handling  qualities  as  seen  by  the  pilot. 

A recent  series  of  fixed  base  simulator  evaluations  examined  these  and  other  variations  in  the 
pitch  axis  control  during  landing.  This  was  done  to  determine  if  improvement  is  possible  by  changes 
to  the  software.  These  simulations  are  still  in  progress.  A complete  treatment  is  beyond  the  scope 
of  this  paper  but  some  of  the  findings  have  been  the  following: 

1.  None  of  the  changes  made  more  than  a 0.5  improvement  in  the  Cooper-Harper  rating  or  a 26  per- 
cent improvement  in  landing  performance  with  respect  to  the  existing  baseline  system.  Twice  that  much 
would  be  required  to  consider  a change. 


WE  CURRENTLY  HAVE 


[inherent  AIRFRAME 
CHARACTERISTIC 


AIRFRAME  WITH 
CONTROL  SYSTEM 


S (S  + 0.45) 


1 1 


WE  SHOULD  HAVE 

• AS  ABOVE  BUT  WITH  (S  + 1.5)  = (S  + 0.45) 

• LIKE  CONVENTIONAL  AIRCRAFT 

• BETTER  Nz  RESPONSE  BUT  MORE  0 OVERSHOOT 


FIGURE  1.-  WHAT  DOES  IT  ALL  MEAN? 


FIGURE  2.-  FLIGHTPATH  RESPONSE  DEGRADATION 
WITH  THE  PRESENT  SYSTEM. 
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2.  The  systems  with  the  best  landing  performance  were  not  rated  the  best  by  the  pilots.  In 
fact,  the  two  systems  with  the  best  landing  performances  were  both  rated  worse  than  the  baseline. 

3.  The  lead/laq  stick  filter  addition  to  the  baseline  was  one  of  the  two  best  systems  from  a 
performance  standpoint  (group  1 out  of  8)  even  though  not  properly  implemented  in  detail. 

4.  The  baseline  system  was  in  group  3 out  of  8 from  a performance  standpoint.  It  was  rated  in 

group  2 out  of  5 (C.H.  = 3.5)  by  the  pilots  which  is  quite  consistent. 

These  systems  did  not  all  have  the  same  inner  loop  gain  or  gain  margin.  Consequently  it  is  not 
immediately  obvious  what  aspect  of  a given  system  caused  a certain  result.  Also,  from  the  pilots' 
comments,  it  is  clear  that  there  are  many  subtleties  that  affect  the  rating  of  a system.  These 

subtleties  include  having  to  control  across  the  hand  controller  detent  or  use  push  force  right  at 

touchdown.  It  is  also  clear  that  the  pilots'  first  priority  is  attitude  response.  Systems  with  sig- 
nificant overshoot  tended  to  be  downgraded  even  though  they  might  have  better  flight  path  response. 
This  probably  resulted  from  training  and  adjustment  to  accommodate  the  existing  system.  Changing  the 
system  response  characterstics  to  achieve  better  landing  performance  would  probably  require  a signifi- 
cant amount  of  retraining.  The  improvement  needs  to  be  significant  enough  to  warrant  the  effort. 


CONSIDERATIONS  FOR  NEXT  TIME 


It  is  interesting  to  consider  what  should  be  done  from  a handling  qualities  standpoint  if  a sec- 
ond-generation Shuttle  were  to  be  designed.  There  are  at  least  two  major  objectives  to  address. 
First,  there  should  be  an  effort  to  provide  more  definitive  requirements  for  mission  phases  other 
than  approach  and  landing.  A significant  amount  of  basic  knowledge  is  available  that  would  be  use- 
ful. However,  it  needs  to  be  organized  and  written  down.  The  effort  would  probably  expose  holes 
where  further  activity  would  be  beneficial.  Future  missions  will  serve  to  increase  the  understanding 
of  these  requirements  and  allow  a more  knowledgeable  compromise  with  new  vehicle  configurations  if 
available  at  the  outset. 

The  other  major  objective  should  be  to  improve  the  pitch  axis  handling  qualities  for  landing. 
First,  serious  consideration  should  be  given  to  arrange  the  vehicle  configuration  such  that  fast- 
acting direct  lift  control  is  available  for  landing.  This  could  be  by  means  of  canard  control  sur- 
faces or  wing  flaps  if  it  is  a tail -controlled  vehicle.  Possibly  even  the  reaction  control  system 
could  be  used  if  it  were  designed  with  this  in  mind.  Secondly,  there  needs  to  be  a strong  influence 
at  the  beginning  of  the  program  to  keep  the  flight  control  system  time  delays  to  a minimum.  Addi- 
tional time  delays  tend  to  creep  in  and  this  is  clearly  detrimental  though  somewhat  difficult  to 
quantify.  Specific  requirements  should  be  imposed  for  end-to-end  system  response  delays.  In  addi- 
tion, the  design  and  development  effort  must  be  monitored  closely.  Aggressive  action  should  be  taken 
where  necessary  to  ascertain  that  proper  attention  is  given  to  meeting  the  requirements.  The  inner 
flight  control  loops  should  be  processed  at  50  cycles/second  or  more  for  landing.  The  redundant  ac- 
tuator design  should  be  reviewed  to  quantify  and  determine  ways  to  minimize'  the  response  delays  to 
small  signals.  Finally,  a hardware  feed  forward  provision  should  be  implemented  so  that  small  ampli- 
tude, high  passed  analog  signals  can  be  sent  directly  to  the  actuators  from  the  hand  controller  or 
sensor  sumning  junction  to  bypass  the  digital  delays  and  overcome  the  small  amplitude  actuator  non- 
linearities.  These  improvements  are  relatively  easy  during  the  design  process  but  nearly  impossible 
to  change  after  the  hardware  is  built. 
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ABSTRACT 


The  shuttle  program  took  on  the  challenge  of  providing  a manual  landing  capability  for  an  opera- 
tional vehicle  returning  from  orbit.  Some  complex  challenges  were  encountered  in  developing  the  longi- 
tudinal flying  qualities  required  to  land  the  orbiter  manually  in  an  operational  environment.  Approach 
and  landing  test  flights  indicated  a tendency  for  pilot-induced  oscillation  near  landing.  Changes  in 
the  operational  procedures  reduced  the  difficulty  of  the  landing  task,  and  an  adaptive  stick  filter  has 
been  incorporated  to  reduce  the  severity  of  any  pilot-induced  oscillatory  motions.  Fixed-base,  moving- 
base,  and  in-flight  simulations  were  used  for  the  evaluations,  and  in  general,  flight  simulation  has 
been  the  only  reliable  means  of  assessing  the  low-speed  longitudinal  flying  qualities  problems.  Over- 
all, the  orbiter  control  system  and  operational  procedures  have  produced  a good  capability  to  routinely 
perform  precise  landings  with  a large,  unpowered  vehicle  with  a low  lift-to-drag  ratio. 


INTRODUCTION 

The  flying  qualities  task  of  manually  landing  an  unpowered  vehicle  with  a low  lift-to-drag  ratio 
(L/D)  is  a difficult  one  and  has  been  a subject  of  NASA  research  for  many  years.  One  of  the  first 
flight  programs  to  seriously  address  the  problems  associated  with  an  entry  from  orbit  was  the  X-1 5 
research  airplane  program  from  1959  to  1968.  The  objectives  of  the  X-1 5 program  included  an  evaluation 
of  unpowered  landings  from  the  last  part  of  an  entry  from  orbit  to  touchdown.  The  program  consisted  of 
199  flights,  with  routine  landings  made  on  the  Edwards  dry  lakebed.  After  the  X-1 5 program,  a series 
of  lifting  body  configurations,  which  were  more  representative  of  the  aerodynamic  configurations  that 
would  be  required  for  entry,  were  evaluated  in  the  terminal  area  and  landing  phases.  Two  landings  were 
made  during  the  program  on  the  4570-m  (15,000-ft)  concrete  runway.  These  early  vehicles  were  quite 
small  and  simple  in  design.  The  control  systems  generally  consisted  of  only  angular  rate  feedbacks 
since  the  vehicles  had  aerodynamic  static  stability.  The  guidance  system  consisted  of  ground  controller 
calls  based  on  radar  tracking  of  the  flightpath.  Nonetheless,  the  lifting  body  program  demonstrated 
the  feasibility  of  having  a pilot  make  a manual  landing  of  an  unpowered  entry  vehicle  with  a low  L/D  on 
a conventional  runway. 

From  this  modest  beginning,  the  shuttle  program  took  a bold  and  pioneering  step  to  produce  a 
vehicle  that  would  return  from  orbit  and  land  on  a conventional  runway.  To  meet  this  goal  would  require 
an  entry  vehicle  with  an  operational  capability  to  land  day  or  night  in  all  types  of  weather  using  a 
4570-m  (15,000-ft)  runway.  The  low-speed  longitudinal  control  system  was  further  complicated  by  the 
requirement  for  a center-of -gravity  position  that  ranged  from  statically  stable  to  statically  unstable. 
At  the  time  the  orbiter  was  designed,  the  flying  qualities  data  base  was  limited  for  aircraft  with 
advanced  control  systems  similar  to  that  required  to  meet  the  orbiter  design  requirements.  Little 
experience  existed  in  the  use  of  high-gain,  digital  flight  control  systems  for  statically  unstable 
aircraft,  and  the  influence  of  the  time  delay  between  the  pilot  input  and  the  airplane  response  would 
not  be  fully  appreciated  until  much  later,  based  on  experience  with  the  orbiter  and  highly  augmented 
fighter  aircraft.  In  general,  the  flying  qualities  design  criteria  reflected  experience  with  more  con- 
ventional airplanes  which  only  required  very  simple  control  systems. 

This  paper  discusses  some  of  the  complex  challenges  encountered  in  developing  the  longitudinal 
flying  qualities  required  to  land  the  orbiter  manually  in  an  operational  environment.  The  results  of 
tests  that  have  led  to  modifications  are  discussed,  as  well  as  the  results  of  some  additional  testing 
that  may  lead  to  further  control  system  modifications.  These  studies  have  included  fixed-base,  moving- 
base,  and  in-flight  simulation.  Some  of  the  simulation  techniques  required  to  examine  the  low-speed 
longitudinal  flying  qualities  problems  are  also  addressed. 


OPERATIONAL  TECHNIQUE  FOR  MANUAL  LANDING  CAPABILITY 

The  most  significant  task  in  an  unpowered  vehicle  is  that  of  energy  management.  In  the  terminal 
area  phase,  the  orbiter's  speedbrakes  are  used  in  conjunction  with  angle  of  attack  and  S-turns  to  put 
the  orbiter  in  approximately  the  correct  energy  state  at  the  start  of  the  landing  phase  at  an  altitude 
of  about  3700  m (12,000  ft).  The  first  part  of  the  landing  phase  (fig.  1)  is  devoted  to  the  final 
energy  management  maneuver  and  consists  of  a steep  glide  slope  (approximately  20°)  with  a fixed  aim 
point  relative  to  the  runway  and  a constant  equivalent  airspeed.  The  objective  of  this  phase  is  to 
reach  an  energy  window  at  about  610  m (2000  ft)  above  the  runway  with  the  correct  speed  and  flightpath. 
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Altitude 
(not  to  scale) 


Since  there  is  no  active  energy  management 
below  this  point,  the  steep  glide  slope  man- 
euver becomes  the  critical  energy  management 
task  for  both  the  manual  and  automatic  land- 
ings* The  pitch-axis  task  has  several  levels 
of  automation,  depending  on  the  guidance 
information.  With  the  normal  navigational 
and  guidance  information  available,  the  glide 
slope  can  be  tracked  in  the  autopilot  mode  or 
the  manual  control  mode.  In  the  manual  mode, 
the  task  consists  of  manually  tracking  the 
guidance  command  information  displayed  to  the 
pilot  on  the  flight  director.  If  no  guidance 
information  is  available,  the  glide  slope  can 
be  established  visually  using  a light-beam 
system  on  the  ground.  In  all  cases,  the 
speed  can  be  maintained  by  manual  or  auto- 
matic modulation  of  the  speedbrakes. 

Having  established  the  proper  energy, 
the  final  landing  phase  is  begun  at  about 
610  m (2000  ft)  above  the  runway.  Again, 
there  are  several  levels  of  automation 
available:  the  autopilot  mode;  the  flight 

director  mode,  which  when  combined  with  the 
heads-up  display  provides  guidance  inform- 
ation until  touchdown;  and  the  completely 
manual  mode,  in  which  the  landing  is  made 
using  the  normal  visual  and  motion  references. 

A 1.2  to  1.5g  flare  is  used  to  transition  from  the  steep  glide  slope  to  a glide-slope  angle  of  about  1°. 
In  addition  to  the  visual  and  acceleration  cues,  the  pilot  has  cockpit  displays  of  pitch-rate  informa- 
tion to  assist  in  establishing  the  initial  pitch  rate  during  the  flare.  The  final  glide  slope  is  quite 
shallow,  and  a small  final  flare  is  made  to  reduce  the  rate  of  sink  to  a desirable  level.  The  flare  to 
touchdown  is  often  made  as  one  continuous  maneuver  without  actually  establishing  the  final  glide  slope. 
This  operational  technique  provides  an  extremely  versatile  capability  for  establishing  the  desired 
touchdown  conditions  under  all  types  of  normal  and  contingency  situations. 


Figure  1.  Landing  trajectory . 


APPROACH  AND  LANDING  TESTS 


In  1977,  the  low-speed  characteristics  of  the  orbiter  were  evaluated  in  flight  during  the  approach 
and  landing  test  (ALT)  program.  The  first  four  landings  were  on  the  Edwards  dry  lakebed;  the  fifth 
landing  was  on  the  4570-m  (15,000-ft)  concrete  runway.  These  tests  validated  the  concept  of  landing  a 
large,  low  L/D  vehicle  on  a standard  runway.  In  general,  the  flying  qualities  were  quite  good.  The 
normal  acceleration  control  in  turns  was  good,  although  the  vehicle  was  very  responsive  in  pitch,  which 
combined  with  the  light  stick  forces  made  pitch  control  sensitive.  The  tests  were  not  without  problems, 
however.  On  the  fifth  flight  (the  concrete  runway  landing),  a tendency  for  pilot-induced  oscillation 
( pio ) in  both  pitch  and  roll  was  exhibited  near  touchdown.  Postflight  analysis  indicated  that  the  prob- 
lem, which  was  primarily  in  the  pitch  axis,  resulted  in  rate  limiting  of  the  elevons.  Because  of  the 
priority  rate  limit  logic  that  allocates  elevon  surface  rate  for  both  pitch  and  roll  commands,  the  rate 
limiting  in  the  pitch  axis  produced  rate  limiting  in  the  roll  axis,  resulting  in  the  roll  oscillations. 

Although  this  series  of  flights  demonstrated  the  landing  capabilities  of  the  orbiter,  it  also 
indicated  that  additional  work  would  be  necessary  to  make  the  longitudinal  flying  qualities  satisfac- 
tory for  the  manual  landing  task.  In  particular,  there  was  a need  to  evaluate  the  cause  and  signifi- 
cance of  the  PIO  tendencies  observed  in  the  ALT  flights.  In  the  following  sections,  the  general  nature 
of  the  longitudinal  control  problem  is  discussed,  as  well  as  some  of  the  modifications  that  have  been 
evaluated • 


LONGITUDINAL  CONTROL  CHARACTERISTICS 


The  shuttle  orbiter  has  two  modes  that  affect  longitudinal  control.  The  first  mode  is  pitch  atti- 
tude control.  A major  factor  contributing  to  pilot-induced  oscillatory  motions  in  this  mode  is  the 
effective  time  delay  between  the  pilot  input  and  the  airplane  response.  The  actuators  contribute  a 
significant  delay,  as  they  do  on  most  aircraft.  The  structural  and  smoothing  filters,  which  are 
required  because  of  the  high-gain  feedback  control  system,  contribute  additional  significant  delays. 

The  digital  control  system  also  contributes  delay  because  of  the  average  sampling  time  and  the  computa- 
tion time.  A second  factor  that  contributes  to  pitch  attitude  PIO  tendencies  is  the  nonlinear  stick 
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gearing,  which  is  a method  of  obtaining  good  sensitivity  around  the  neutral  stick  position  while  retain- 
ing a good  maximum  pitch  rate  or  normal  acceleration  capability.  Unfortunately,  in  any  kind  of  oscil- 
latory maneuver,  any  divergence  results  in  increased  stick  inputs,  which  increases  the  effective  pilot/ 
stick  gain  caused  by  the  nonlinear  stick.  As  a result,  there  is  an  inherent  tendency  for  oscillations 
to  diverge  rapidly  once  a slight  divergence  occurs.  In  simulations  of  the  PIO  it  is  interesting  that 
there  were  almost  no  instances  of  slowly  divergent  oscillations.  If  the  oscillation  began  to  diverge, 
it  rapidly  became  a fully  developed  PIO,  resulting  in  loss  of  control. 


The  second  mode  involved  in  longitudinal  control  is  altitude  or  flightpath  control.  A primary 
factor  that  makes  altitude  control  difficult  is  the  loss  of  lift  caused  by  elevon  deflection.  Because 
of  this  factor,  a nose-up  pitch  command  initially  results  in  a downward  acceleration  at  the  center  of 
gravity  (fig.  2).  At  the  pilot  location,  which  is  near  the  center  of  rotation,  there  is  a delay  of 

approximately  0.5  sec  before  any  motion  is  detec- 
ted by  the  pilot.  This  delay,  in  combination 
with  the  sluggish  rise  time  of  the  acceleration 
to  its  steady-state  value,  makes  it  difficult  for 
the  pilot  to  accurately  control  altitude.  The 
high  cockpit  location  and  poor  visibility  also 
contribute  to  the  inability  of  the  pilot  to  accu- 
rately judge  altitude,  especially  near  touchdown. 


Figure  2.  Response  characteristics  of  the  orbiter 
for  a step  pilot  input • Airspeed  - 190  knots • 


These  two  modes  have  been  examined  in  terms 
of  a pilot  closed-loop  system  with  a pitch- 
attitude  inner  loop  and  an  altitude  outer  loop 
(ref.  1).  Regions  of  stability  as  a function  of 
pilot  gain  are  shown  in  figure  3 for  several  mag- 
nitudes of  control  input  and  indicate  that 
because  of  the  nonlinear  stick  gearing,  stability 
decreases  as  stick  deflection  increases.  The 
Neal/Smith  analysis  technique  of  reference  2 has 
also  been  used  to  analyze  the  closed-loop  atti- 
tude control;  the  results  are  shown  in  figure  4 in 


terms  of  the  amount  of  pilot  lead  and  the  amount  of  resonance  experienced  for  various  amounts  of  closed- 
loop  bandwidth.  As  the  task  becomes  more  demanding,  the  pilot  tries  to  increase  the  pilot-vehicle  band- 
width to  get  better  response.  The  pilot  lead  required  is  generally  indicative  of  the  amount  of  pilot 
workload,  and  the  resonance  is  a measure  of  the  degree  of  the  PIO  tendencies.  Figure  4 shows  that  the 


Pilot 

attitude 

gain 


Figure  3 • Effect  of  nonlinear  stick  gearing  on 
pilot-vehicle  closed-loop  stability • 


Bandwidth,  rad/sec 

Figure  4.  Pilot-vehicle  closed-loop  character- 
istics using  Seal /Smith  analysis  of  reference  2. 
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orbiter  has  reasonably  good  handling  qualities  for  low  bandwidths,  but  as  the  bandwidth  increases 
there  is  an  increase  in  the  pilot  lead  required  and  a sharp  increase  in  the  PIO  tendency* 


DEVELOPMENT  OF  THE  STS-1  CONFIGURATION 


After  the  ALT  flights,  two  approaches  were  pursued  to  improve  the  landing  characteristics.  The 
first  was  to  make  the  task  easier,  thus  reducing  the  need  for  large  values  of  closed-loop  bandwidth? 
the  second  was  to  reduce  the  tendency  toward  PIO  when  large  bandwidths  were  used. 


TIME-DELAY  AND  TASK  EFFECTS 

One  of  the  main  causes  of  the  pitch  attitude  PIO  is  the  interaction  of  time  delay  and  high- 
bandwidth  requirements.  To  study  this  effect,  a series  of  flights  was  flown  using  the  Dryden  F-8  digi- 
tal fly-by-wire  (DFBW ) airplane  (ref.  3).  The  two  landing  tasks  of  most  interest  were  the  high-workload 
case,  in  which  the  pilot  was  attempting  to  land  precisely  on  a designated  area  of  the  runway,  and  the 
low-workload  case,  where  the  pilot  was  attempting  to  land  on  the  runway  without  concern  for  the  actual 
touchdown  point.  A steep  glide  slope  about  half  that  of  the  orbiter  was  used  for  both  cases,  and  the 
high-workload  case  had  a 46-m  (150-ft)  lateral  offset  at  30  m (100  ft)  above  the  runway.  The  spot- 
landing case  was  similar  to  the  conditions  for  the  ALT  flights.  After  the  ALT  flights,  the  orbiter 
landing  task  was  made  easier  by  basing  the  touchdown  point  on  velocity  rather  than  a fixed  point  on  the 
runway.  This  technique  reduced  the  need  for  high -bandwidth  control  and  made  the  task  more  like  the 
low-workload  task  evaluated  in  the  F-8  DFBW  tests. 

The  results  of  the  F-8  tests  are  shown  in  figure  5 along  with  the  results  from  the  total  in-flight 
simulator  (TIFS)  orbiter  simulation.  For  orbiter  time-delay  values  of  approximately  235  msec,  the 
effect  of  task  is  quite  significant,  and  it 
appears  that  the  current  operational  proce- 
dures for  the  orbiter  produce  a task  that 
is  between  the  low-  and  high-workload  tasks 
of  the  F-8  tests.  These  results  also  indi- 
cate that  time  delay  can  cause  a signifi- 
cant degradation  in  handling  qualities  when 
a high-workload  task  is  performed.  Inter- 
estingly, these  same  results  were  confirmed 
in  a study  of  the  standard  approach  task 
for  fighter  aircraft  (ref.  4).  This  study 
was  instigated  as  a result  of  difficulties 
with  handling  qualities  in  the  landing 
phase  for  several  of  the  latest  generation 
of  fighter  aircraft.  These  aircraft  have 
control  systems  similar  to  the  control  sys- 
tem of  the  orbiter,  with  high-gain  feedback 
systems  requiring  structural  bending  filters 
and  other  filters  that  introduce  signifi- 
cant time  delays.  The  results  for  the 
fighter  aircraft  in  the  landing  task  were 
essentially  the  same  as  for  the  high- 
workload  task  of  the  F-8  study.  These 
tests  have  contributed  significantly  to  the 
understanding  of  time-delay  effects  in 
modern  aircraft,  and  the  results  have  now 
been  incorporated  into  the  current  specifi- 
cations for  military  aircraft. 


To  reduce  the  possibility  of  developing  a large -amplitude  pilot-induced  oscillation  near  the 
ground,  an  adaptive  stick  gain  was  developed  (refs.  5 and  6).  This  system  can  best  be  thought  of  as  a 
closed-loop  bandwidth  limiter.  The  relationship  of  resonance  to  bandwidth  (fig.  4)  shows  that  it  would 
be  highly  desirable  to  restrict  the  pilot  to  bandwidths  less  than  3 rad/sec  to  avoid  large-amplitude 
oscillations.  The  adaptive  stick  gain  algorithm  consists  of  a frequency  detector  combined  with  variable 
stick  shaping  (fig.  6).  The  PIO  filter  reduces  the  stick  gain  by  reducing  the  parabolic  portion  of  the 
stick  gearing  so  that  at  its  maximum  amount  of  reduction,  the  stick  is  very  nearly  linear  (fig.  7).  By 
reducing  the  overall  pilot/stick  gain,  the  PIO  tendency  is  reduced  and,  in  addition,  the  more  linear 
stick  gain  reduces  the  divergent  nature  of  the  PIO  caused  by  the  nonlinear  stick.  Tests  on  the  TIFS 
demonstrated  the  capability  of  reducing  the  PIO  tendencies  of  the  orbiter  in  high-workload  situations. 
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Figure  5.  Time-delay  effects  obtained  from  orbiter 
simulations  and  from  the  F-8  flight  tests  of 
reference  2. 
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Figure  6 • Adaptive  stick- 
gearing concept  to  reduce  PIO 
tendencies  ( ref • 6 ) • 


Frequency, 

rad/sec 


Pilot  input,  deg 

Figure  7.  Example  of  frequency- 
dependent  stick  shaping • 


The  PIO  filter  does  not  significantly  improve  the  flying  qualities  of  the  arbiter,  but  it  does  provide 
some  protection  from  potentially  dangerous,  large -amplitude  oscillations  near  the  ground. 

Another  modification  was  to  increase  the  stick  force  gradient  by  a factor  of  two.  This  decreased 
the  pitch  sensitivity,  thus  reducing  inadvertent  inputs.  It  also  improved  the  pilot* s awareness  of 
impending  PIO  situations.  In  the  orbiter,  there  are  almost  no  acceleration  cues  because  of  the  loca- 
tion of  the  center  of  rotation,  and  the  visual  cues  of  attitude  are  limited  because  of  pilot  location. 
As  a result,  the  pilot  would  not  be  aware  of  any  oscillatory  motion  until  the  amplitude  grew  large. 
With  the  increased  stick  forces,  the  types  of  inputs  that  generate  PIOs  would  be  more  obvious  to  the 
pilot,  and  proper  attention  could  be  given  to  the  oscillatory  motions  before  they  became  a significant 
problem. 


Figure  8 . Orbiter  attitude  response  for  pilot 
pulse  input • Airspeed  * 190  knots . 


Other  changes  made  before  the  orbital  flights 
included  a change  in  the  priority  rate-limiting  logic 
to  reduce  the  interactions  of  the  roll  and  pitch 
axes.  In  addition,  the  pitch  attitude  response  was 
made  slightly  less  sensitive  by  reducing  the  overall 
loop  gains  at  the  landing  condition.  The  result  of 
these  changes  was  a high-gain,  pitch -rate -command 
control  system  which  was  optimized  to  give  excellent 
attitude  control.  With  this  type  of  system,  the 
pilot  can  pull  up  to  a desired  attitude  and  release 
the  stick,  and  the  attitude  will  overshoot  slightly 
and  return  to  the  value  at  which  the  stick  was 
released  (fig.  8).  This  makes  it  extremely  easy  for 
the  pilot  to  establish  a precise  attitude  without 
using  complex  pilot  control  techniques. 


PIO  TENDENCY  AND  SIMULATION 


Analytical  results  can  provide  considerable  insight  into  the  nature  of  flying  qualities  problems, 
but  simulation  has  also  played  an  important  role  in  the  development  and  evaluation  of  the  control  sys- 
tem. Most  of  the  early  studies  of  the  flying  qualities  of  the  orbiter  during  landing  were  performed  on 
a fixed-base  simulation  with  a visual  display  of  the  runway.  The  task  was  generally  not  very  demand- 
ing, and  as  a result  there  was  little  indication  of  any  PIO  tendency.  In  1978  after  the  ALT  experi- 
ence, the  Ames  Flight  Simulator  for  Advanced  Aircraft  (FSAA)  moving-base  simulation  (ref.  7)  and  Cal- 
span  TIFS  facility  (ref.  8)  were  used  to  examine  the  PIO  characteristics  of  the  orbiter.  The  FSAA  is  a 
moving-base  simulator  with  a TV  model-board  visual  display  of  a runway.  The  TIFS  is  an  in-flight  simu- 
lator that  can  reproduce  cockpit  motions  in  addition  to  providing  the  real-life  visual  scene.  A safety 
pilot  is  used  to  prevent  the  evaluation  pilot  from  getting  into  any  dangerous  conditions.  During 
these  evaluations,  the  pilots  evaluated  the  PIO  tendencies  using  the  rating  scale  shown  in  table  1. 
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TABLE  1.  — PIO  RATING  SCALE.  The  histogram  in  figure  9 summarizes  the 

results  obtained.  It  is  clear  from  this 
figure  that  the  FSAA  with  limited  motion  and 
visual  cues  produced  very  little  PIO  tendency 
compared  to  the  TIFS. 

In  1979  and  1980  another  series  of  sim- 
ulations were  made  with  the  Ames  Vertical 
Motion  Simulator  (VMS)  (ref.  9)  and  the  TIFS. 
The  VMS  had  sufficient  vertical  motion  to 
provide  good  vertical  motion  simulation,  but 
it  had  the  same  visual  display  that  was  used 
on  the  FSAA.  In  both  of  these  simulations  a 
very  demanding  task  was  used  to  accentuate 
the  PIO  tendencies.  A 46-m  (150-ft)  lateral 
offset  was  performed  at  30  m (100  ft)  above 
the  runway,  and  a 4.6-m/sec  (15-ft/sec)  ver- 
tical gust  was  introduced  at  an  altitude  of 
approximately  15  m (50  ft).  This  produced  a task  that  would  be  unlikely  in  real  life,  but  it  provided 

a situation  that  produced  a pilot  gain  high  enough  to  make  the  PIO  tendencies  of  the  vehicle  apparent 

to  the  pilot.  The  results  of  these  tests  are  summarized  in  figure  10,  and  a significant  difference 
still  exists  between  the  moving-base  simulation  and  the  flight  simulation.  On  both  of  these  simula- 
tors, after  becoming  familiar  with  the  simulator,  a normal  straight-in  approach  and  landing  could  be 
made  without  evidence  of  a PIO  tendency.  Although  the  PIO  tendencies  were  not  the  same  for  the  two 

simulations,  for  tasks  less  demanding  than  those  that  would  produce  PIOs,  the  two  simulators  produced 

similar  evaluations  of  the  basic  handling  gualities.  The  general  conclusion  from  these  tests  is  that 
flight  simulation  is  probably  the  only  reliable  method  of  evaluating  the  landing  characteristics.  The 
introduction  of  an  artificial  task  produces  pilot  workload  levels  nearer  to  the  workload  levels  that 
can  be  encountered  in  flight,  but  even  flight  simulation  does  not  produce  the  same  sense  of  urgency 
that  the  actual  flight  environment  produces. 


Rating 

Description 

1 

No  undesirable  motions 

2 

Undesirable  motions  that  are  cured  by 
pilot  technique 

3 

Undesirable  motions  that  can  be  cured 
by  sacrificing  the  task  or  by 
increased  effort 

4 

Sustained  nondivergent  oscillations 

5 

Divergent  oscillations  for  abrupt 
maneuvers  only 

6 

Divergent  oscillations  encountered  in 
normal  control 

PIO  rating 

Figure  9.  Comparison  of  PIO  rating  from  the  FSAA 
and  TIFS  simulators  for  the  landing  task  with  the 
ALT  orbiter  configuration • 


PIO  rating 

Figure  10 • Comparison  of  PIO  ratings  from  the  VMS 
and  TIFS  simulators  for  the  landing  task  with  the 
STS  orbiter  configuration • 


ORBITAL  FLIGHTS 


The  first  orbital  flight  of  the  space  transportation  system  (STS),  made  in  1981,  represented  a 
significant  event  in  demonstrating  the  feasibility  of  making  manual  landings  with  an  entry  vehicle. 
Subsequent  flights  have  demonstrated  a capability  to  land  on  a 4570-m  (15,000-ft)  concrete  runway  in  a 
routine  manner.  In  the  early  flights,  variations  in  touchdown  point  and  speed  have  resulted  from  a 
greater-than-predicted  value  of  low-speed  L/D.  Predictions  are  extremely  important  for  the  landing 
phase  because  there  is  no  energy  management  below  610  m (2000  ft),  and  increases  in  L/D  result  in 
higher  touchdown  speeds  or  longer  landings.  With  the  predicted  data  now  updated  with  the  flight 
results,  this  problem  has  been  reduced  significantly.  Overall,  the  STS  flights  have  demonstrated  a 
good  manual  landing  capability,  with  acceptable  landings  being  made  in  a variety  of  wind  and  turbulence 
conditions.  The  capability  demonstrated  so  far  is  especially  impressive  when  one  considers  that  each 
manual  landing  has  been  performed  by  a different  pilot,  thus  reducing  any  of  the  pilot  training  advan- 
tages resulting  from  actual  flight  experience. 
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POTENTIAL  IMPROVEMENTS 


System  for  good  attitude  response 

System  for  good  flightpath  response 


Pitch  rate, 
deg/sec 


2 — 


As  discussed  previously,  one  disadvantage  of  the  current  orbiter  control  system  is  the  sluggish 
response  in  normal  acceleration,  which  makes  flightpath  control  more  difficult.  One  maneuver  that  is 
especially  difficult  is  leveling  off  near  the  ground  (such  as  to  bleed  off  speed  to  obtain  a better 
touchdown  velocity).  This  difficulty,  caused  by  the  problem  with  ballooning,  is  especially  noticeable 
when  in  ground  effects.  Unlike  a conventional  transport,  the  orbiter  has  a considerable  amount  of 
excess  energy  at  a nominal  landing  speed  of  200  knots,  but  because  of  the  rapid  deceleration  (4  to 
5 knots/sec),  any  significant  ballooning  can  result  in  a low-energy  condition  fairly  rapidly.  To 
improve  the  flightpath  response,  it  is  necessary  to  speed  up  the  acceleration  response  by  increasing 
the  amount  of  pitch  rate  overshoot.  The  example  in  figure  11  shows  a faster  acceleration  response, 

which  results  in  better  flightpath  control,  but 
the  attitude  response  drops  back  when  the  stick  is 
released,  which  makes  accurate  pitch  attitude  con- 
trol more  difficult.  Simulator  studies  of  systems 
of  this  type  are  currently  being  conducted,  and  an 
analysis  of  this  type  of  system  is  given  in  refer- 
ence 10.  An  interesting  problem  has  developed  in 
the  effort  to  improve  the  longitudinal  flying 
qualities.  On  the  one  hand,  an  effort  has  been 
made  to  make  the  landing  task  easier,  while  on  the 
other  hand,  an  effort  has  been  made  to  improve  the 
flightpath  control  at  landing.  These  efforts  have 
resulted  in  conflicting  requirements  for  the  pitch 
response  characteristics.  As  the  task  becomes 
easier,  it  is  generally  performed  in  a more  open- 
loop  fashion  and  attitude  becomes  the  primary  var- 
iable to  be  controlled,  which  produces  a require- 
ment for  extremely  good  pitch  attitude  control. 

One  example  of  an  open-loop  control  strategy  is  in 
the  final  flare  and  landing  in  which  the  pilot 
increases  the  vehicle  attitude  a predetermined 
amount  at  the  final  flare  point  and  then  lets  the 
airplane  land  with  minimal  pilot  inputs.  Several 
of  the  landings  to  date  have  been  of  this  type  and 
have  been  quite  successful.  In  contrast  to  this 
technique,  there  is  the  control  strategy  that 
requires  a more  closed-loop  control  of  the  flight- 
path.  This  technique  would  be  especially  appro- 
priate for  nonstandard  landing  situations,  such  as  during  recovery  from  an  automatic  landing  system 
failure  near  the  ground.  To  improve  the  normal  acceleration  response,  this  technique  requires  an 
increase  in  the  pitch  rate  overshoot,  which  is  in  conflict  with  the  good  attitude  response  required 
with  the  more  open-loop  tasks.  Further  test  results  from  both  flight  and  simulation  will  be  required 
to  determine  which  control  technique  (and  therefore,  control  system)  will  provide  the  best  overall 
capability  for  the  manual  control  task  in  the  operational  environment. 


Normal 

acceleration 

9 


Figure  11.  Comparison  of  response  characteristics 
for  good  attitude  response  and  for  good  flightpath 
response • 


CONCLUDING  REMARKS 


The  shuttle  program  was  initiated  as  a bold  and  pioneering  effort  to  develop  a true  spaceplane 
capable  of  returning  from  orbit  and  landing  on  a conventional  runway.  Some  complex  challenges  were 
encountered  in  developing  the  longitudinal  flying  qualities  required  to  land  the  orbiter  manually  in  an 
operational  environment.  Approach  and  landing  test  (ALT)  flights  indicated  a tendency  for  pilot-induced 
oscillation  near  landing.  Changes  in  the  operational  procedures  have  reduced  the  difficulty  of  the 
landing  task,  and  an  adaptive  stick  filter  has  been  incorporated  to  reduce  the  severity  of  pilot- 
induced  oscillatory  motions.  Fixed-base,  moving-base,  and  in-flight  simulations  have  been  used  during 
the  evaluations,  and  in  general,  flight  simulation  has  been  the  only  reliable  means  of  assessing  the 
low-speed  longitudinal  flying  qualities  problems.  Some  additional  refinements  may  still  be  required  to 
improve  the  flying  qualities  for  the  manual  landing  task,  and  two  types  of  systems  appear  viable, 
depending  on  the  nature  of  the  task:  one  emphasizes  attitude  control,  and  the  other  emphasizes  flight- 

path  control.  Further  flight  experience  will  contribute  additional  information  about  the  manual 
landing  task,  especially  in  regard  to  the  interfacing  of  the  manual  task  to  the  automatic  landing  mode 
and  the  heads-up  display  (HUD)  flight  director  mode  in  the  operational  situation.  Overall,  however, 
the  orbiter  control  system  design  and  the  operational  procedures  have  met  the  objective  of  providing 
the  flying  qualities  necessary  for  a manual  landing.  An  impressive  manual  landing  capability  for  an 
unpowered  vehicle  with  a low  lift-to-drag  ratio  has  been  demonstrated,  and  precision  landings  are  now 
being  made  routinely.  The  shuttle  program  has  used  many  advanced  technologies  and  demonstrated  their 
application  for  the  first  time  in  an  operational  environment.  In  addition  to  providing  an  operational 
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space  transportation  system,  the  orbiter  development  program  has  also  made  a significant  contribution 
to  the  generic  flying  qualities  and  flight  control  system  technology  for  advanced  aircraft. 
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ABSTRACT 


The  phase  B Space  Shuttle  systems  definition  studies  resulted  in  a generic  configuration  consisting 
of  a delta  wing  orbiter,  and  two  solid  rocket  boosters  (SRB)  attached  to  an  external  fuel  tank  (ET) . 

The  initial  challenge  facing  the  aerodynamic  community  was  aerodynamically  optimizing,  within  limits, 
this  configuration.  As  the  Shuttle  program  developed  and  the  sensitivities  of  the  vehicle  to  aero- 
dynamics were  better  understood  the  requirements  of  the  aerodynamic  data  base  grew.  Adequately  charac- 
terizing the  vehicle  to  support  the  various  design  studies  exploded  the  size  of  the  data  base  to  pro- 
portions that  created  a data  mo deling /management  challenge  for  the  aerodynamic is t.  The  ascent  aero- 
dynamic data  base  originated  primarily  from  wind  tunnel  test  results.  The  complexity  of  the  configura- 
tion rendered  conventional  analytic  methods  of  little  use.  Initial  wind  tunnel  tests  provided  results 
which  included  undesirable  effects  from  model  support  structure,  inadequate  element  proximity,  and 
inadequate  plume  simulation.  The  challenge  to  improve  the  quality  of  test  results  by  determining  the 
extent  of  these  undesirable  effects  and  subsequently  develop  testing  techniques  to  eliminate  them  was 
imposed  on  the  aerodynamic  community.  The  challenges  to  the  ascent  aerodynamics  community  documented 
in  this  paper  are  unique  due  to  the  aerodynamic  complexity  of  the  Shuttle  launch.  Never  before  has  such 
a complex  vehicle  been  aerodynamically  characterized.  The  challenges  were  met  with  innovative  engineer- 
ing analyses/methodology  development  and  wind  tunnel  testing  techniques. 


INTRODUCTION 


During  first  stage  flight,  which  for  purposes  of  this  paper  corresponds  to  the  flight  regime  from 
a Mach  number  of  0.60  through  SRB  separation,  aerodynamic  data  bases  were  required  to  support  various 
subsystem  design  studies.  Over-all  vehicle  aerodynamic  characterization  was  required  for  vehicle  per- 
formance analyses,  vehicle  structural  design  analyses,  and  SRB  separation  system  design  studies.  More 
detailed  aerodynamic  inputs  were  required  for  venting  analyses,  protuberance  design  studies,  tile  load 
studies,  and  the  ascent  air  data  system  design  study.  This  paper  discusses  the  aerodynamic  challenges 
and  consequent  approaches/techniques  to  overcome  them  relative  to  the  aerodynamic  characterization  of 
the  Space  Shuttle  launch  vehicle  (SSLV) , its  four  elements  in  proximity  (orbiter,  external  tank,  two 
SRBs),  and  the  orbiter's  basic  components  (wing,  elevons,  and  vertical  tail).  Three  basic  challenges 
are  addressed  in  terms  of  an  ascent  launch  vehicle  aerodynamic  data  base  and  a SRB  separation  aero- 
dynamic data  base. 


CHALLENGE:  AERODYNAMIC  OPTIMIZATION  OF  BASIC  GENERIC  CONFIGURATION 

The  phase  B Space  Shuttle  systems  definition  studies  resulted  in  a generic  launch  configuration 
consisting  of  a delta  wing  orbiter  and  two  solid  rocket  boosters  attached  parallel  to  an  external  fuel 
tank.  The  evolution  of  this  generic  configuration  (Fig.  1)  to  its  present  form  is  the  result  of  many 
system  and  subsystem  optimization  studies.  Preeminent  among  these,  in  the  early  1970's,  were  perform- 
ance trade  studies,  guidance  and  control  design  studies,  and  attach  structure  sizing  studies.  Because 
vehicle  aerodynamics  is  a basic  input  to  these  studies,  the  ascent  aerodynamic  community  was  initially 
challenged  to  provide  a data  base  that  would  allow  configuration  optimization  from  an  aerodynamic 
standpoint.  This  challenge  was  met  by  several  parametric  configurational  studies  in  the  early  1970's. 
These  studies  provided  a data  base  for  determining  the  relative  aerodynamic  effect  of  ET  and  SRB  nose 
shapes,  SRB  location  (longitudinal  and  radial)  on  the  ET,  and  orbiter  incidence  relative  to  the  ET. 

The  significant  results  of  these  studies  (Fig.  2)  showed  that  an  ogive  ET  nose  shape  produced  the  least 
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launch  vehicle  drag  and  consequently  the  best  aerodynamic  performance;  that  reducing  the  orbiter  inci- 
dence to  a minimum  would  minimize  attach  structure  loads  by  reducing  the  orbiter  longitudinal  aero- 
dynamics; and  that  moving  the  SRBs  down  and  aft  reduced  launch  vehicle  drag,  increased  stability  by 
moving  the  aerodynamic  center  aft,  and  minimized  aerodynamic  interference  on  the  orbiter.  This  move- 
ment of  the  SRBs  also  reduced  the  probability  of  contact  with  the  orbiter  wing  during  SRB  separation. 

In  the  1975  time  frame,  after  the  major  configurational  changes  had  taken  place,  additional  parametric 
drag  reduction  studies  were  conducted  to  support  on-going  performance  improvement  trade  studies. 
Innovative  aerodynamic  fairing  designs  were  generated  (Fig.  3)  and  their  drag  reducing  potential  inves- 
tigated. Several  configurations  reduced  drag  (Fig.  3)  and  consequently  improved  aerodynamic  performance. 
However,  weight  and  manufacturing  cost  proved  too  formidable  thus  negating  their  benefits. 


CHALLENGE:  DEVELOPMENT /MANAGEMENT  OF  REQUIRED  AERODYNAMIC  DATA  BASE 

The  initial  concept  of  the  launch  vehicle  aerodynamic  data  base  was,  relative  to  the  final  product, 
simple.  With  both  the  Space  Shuttle  main  engine  (SSME)  and  SRB  nozzles  having  gimbal  capability, 
sufficient  control  authority  existed  to  negate  using  aerodynamic  control  surfaces  during  ascent.  The 
elevons  could  be  set  in  a single  position  for  the  entire  ascent  flight  regime.  Element  proximity  aero- 
dynamics were  considered  secondary  inputs  to  the  attach  structure  design  because  thrust  and  inertial 
forces  were  so  much  larger.  Therefore,  the  fidelity  of  the  required  launch  vehicle  data  base  was  con- 
sidered relatively  unimportant.  Even  though  it  was  understood  that  booster  separation  motors  (BSM) 
would  change  the  aerodynamic  flowfield  associated  with  the  launch  vehicle  at  SRB  separation,  the  degree 
of  change  was  underestimated.  This  was  primarily  due  to  a lack  of  separation  system  requirement  defini- 
tion and  a lack  of  understanding  of  the  criticality  of  controlling  the  nonlongitudinal  aerodynamic 
forces  to  ensure  no  recontact. 

As  the  Shuttle  program  developed  and  the  sensitivities  of  the  vehicle  to  aerodynamics  were  better 
understood  the  requirements  of  the  aerodynamic  data  bases  grew.  Structural  loads  studies  of  the  elevon 
actuator  and  wing  structure  showed  capability  exceedances.  This  dictated  scheduled  elevon  movement 
as  a function  of  Mach  number  (Fig.  4)  to  maintain  actuator  and  wing  structure  within  allowable  limits. 
Because  trajectory  parameters  affecting  hinge  moments  would  vary  from  flight  to  flight,  and  because  of 
the  inclusion  of  uncertainties  on  the  wind  tunnel  derived  hinge  moments  for  any  set  condition,  an  active 
elevon  load  relief  system  was  implemented  to  ensure  no  elevon  actuator  overload.  This  elevon  movement 
also  changed  the  orbiter  proximity  aerodynamics  which  had  now  been  determined  to  have  a significant 
impact  to  the  attach  structure  loads.  Consequently,  the  launch  vehicle  aerodynamic  data  base  now  had  to 
include  the  effects  of  elevon  movement.  With  the  realization  of  the  acute  sensitivity  of  the  vehicle 
to  ascent  aerodynamics,  particular  attention  now  had  to  be  paid  to  the  fidelity  of  the  launch  vehicle 
data  base.  That  is,  the  seemingly  minor  effects  of  the  distribution  between  the  elements  of  the  airload 
on  the  attach  structure,  the  asymmetry  created  by  the  ET  protuberances,  and  the  SSME/SRB  plume  effects 
on  the  forebody  became  significant.  The  sensitive  orbiter  thermal  protection  tiles  imposed  a stringent 
design  requirement  (minimized  BSM  exhaust  plume  impingement)  on  the  SRB  separation  system.  This  dic- 
tated high  BSM  thrust,  over  a very  short  burn  time,  and  a particular  orientation  of  the  BSMs  (Fig.  5). 
Elevated  thrust  was  required  to  account  for  the  cosine  losses  associated  with  the  BSM  40  deg  pitch  and 
shallow  20  deg  inboard  roll  angles.  The  combination  of  high  thrust  and  forward  facing  jets  in  the  SRB 
nose  frustum  greatly  amplified  the  anticipated  BSM  exhaust  plume  effect  on  the  vehicle  flowfield  (Fig. 
6).  This  placed  greater  emphasis  on  the  fidelity  of  the  data  base  methodology  and  attached  more  sig- 
nificance to  the  BSM  plume  scaling  parameters,  utilized  for  wind  tunnel  testing,  in  the  data  base. 
Naturally,  with  the  better  understanding  of  the  vehicle* s acute  sensitivity  to  aerodynamics,  coupled 
with  questionable  wind  tunnel  test  results  (to  be  discussed  later),  the  uncertainties  on  the  aero- 
dynamic data  bases  also  became  prominent  inputs  to  the  various  discipline  studies.  Therefore,  adequate 
aerodynamic  characterization  of  the  vehicle  to  support  the  various  design  studies  exploded  the  size/ 
complexity  of  the  data  bases  to  proportions  that  created  a data  modeling /management  challenge  for  the 
aerodynamicist.  However,  math  modeling  methodology  which  included  the  effects  of  the  potential  changing 
vehicle  parameters  on  aerodynamics  and  their  associated  uncertainties  was  developed.  This  modeling 
methodology  satisfied  the  user  discipline  requirements  and  provided  adequate  aerodynamic  data  bases  for 
design  studies. 


LAUNCH  VEHICLE  AERODYNAMIC  DATA  BASE 

Aerodynamics  represent  external  applied  forces  to  which  the  vehicle  as  a whole  and  its  discrete 
structure  reacts  in  flight.  Therefore,  historically,  launch  vehicle  aerodynamic  data  bases  are  com- 
posed of  two  parts:  a static  stability  data  base  which  constitutes  the  resultant  three  aerodynamic 

force  and  three  moment  coefficients,  and  the  airloads  data  base  which  is  comprised  of  distributed 
localized  pressure  coefficients  over  the  geometry  of  the  vehicle.  Naturally,  the  integration  of  the 
airloads  data  base  into  resultant  forces/moments  must  equal  the  static  stability  force/moment  data  to 
ensure  consistency  between  the  various  system  design  studies  relative  to  overall  vehicle  design.  The 
Space  Shuttle  launch  vehicle  aerodynamic  design  data  base,  in  this  respect,  is  no  different.  The 
uniqueness  of  the  Shuttle  data  base  is  that  five  vehicles  (Fig.  7)  must  be  dealt  with  in  a consistent 
fashion  — the  mated  vehicle  and  its  elements  (orbiter,  ET,  LSRB,  RSRB) . Since  each  of  the  elements 
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contribute  significantly  to  the  mated  vehicle  aerodynamic  characteristics,  none  can  be  treated  as  a 
simple  protuberance  with  relative  minor  interference  effects.  Each  must  be  dealt  with  as  an  independent 
element  in  proximity  to  others.  Additionally,  the  data  base  includes  aerodynamic  characterization  of 
three  orbiter  components  — wing,  vertical  tail,  and  elevons  (inboard  and  outboard). 

In  the  initial  planning  of  the  launch  vehicle  aerodynamic  data  base  the  aerodynamicist  had  to  con- 
sider, along  with  the  inherent  characteristics  of  the  basic  outer  moldlines  of  the  generic  vehicle,  the 
interference  effects  of  the  ET  and  SRB  protuberances,  the  airloads  on  the  attach  structure  and  its  inter- 
ference effect,  and  the  significant  effect  of  the  SRB  and  SSME  exhaust  plumes.  Consideration  also  had 
to  be  given  to  the  primary  source  of  the  data  base  — the  wind  tunnel.  Ideally,  the  aerodynamicist 
desired  to  utilize  a single  high  fidelity  model  to  simultaneously  determine  both  the  static  stability 
force  and  moments  and  the  distributed  pressures  — including  plume  effects.  This,  however,  was  not 
possible  due  to  the  physical  limitations /complexity  of  a model  to  obtain  the  data  and  the  interference 
effects  of  the  model  support  system  required  to  supply  the  high  pressure  gas  for  the  plume  simulations. 
Early  In  the  Shuttle  program,  these  considerations  were  hampered  by  a lack  of  knowledge  of  how  to 
properly  simulate  the  plumes  and  the  fact  that  few  wind  tunnel  facilities  had  the  capability  of  supplying 
an  auxiliary  high  pressure  air  supply  for  plume  testing.  Therefore,  a methodology  was  derived  to 
account  for  these  considerations  and  work  around  the  problems  associated  with  generating  a consistent 
launch  vehicle  data  base  through  combination  of  results  from  different  types  of  wind  tunnel  tests. 

The  total  coefficient  (Fig.  8)  is  comprised  of  forebody  and  base  characteristics.  Furthermore, 
the  forebody  coefficients  are  separated  into  plume-off  (p-off)  data  and  plume-on  (p-on)  increments  to 
account  for  the  effects  of  the  plumes.  This  formulation  permitted  the  determination  of  the  most  sig- 
nificant aerodynamic  characteristics,  the  p-off  forebody  data,  from  one  test  (A  in  Fig.  8)  and  the 
plume  effects  from  an  independent  test  (B  in  Fig.  8).  This  minimized  the  model  support  system  effects 
in  the  data  base.  Plume-off  base  environments  on  the  models  are  removed  from  the  total  measured  test 
(A)  results  to  create  p-off  forebody  data.  These  base  environments  are  irrelevant  to  the  data  base 
because  of  the  model  support  system  interference  and  the  overwhelming  changes  created  by  the  SRB /SSME 
exhaust  plumes.  By  including  the  forebody  plume  effects  as  p-on  minus  p-off  increments  the  effect  of 
the  model  support  system  required  for  plume  testing  (B)  is  reduced  to  a second  order  effect.  The  base 
characteristics  are  determined  from  the  plume  test.  By  utilizing  the  measured  p-on  base  pressures  from 
test  (B)  rather  than  p-on  minus  p-off  increments  to  be  applied  to  the  p-off  base  environments  from  test 
(A),  the  model  support  system  effects  on  the  base  characteristics  are  eliminated  and  the  effects  of  the 
plumes  are  adequately  included  in  the  data  base.  The  airloads  data  base  is  formulated  in  much  the  same 
manner.  The  p-off  forebody  pressure  coefficient  distributions  over  the  geometry  of  the  vehicle  are 
determined  independently  of  the  p-on  pressure  coefficient  increments  and  then  combined.  Again,  with 
this  formulation  the  model  support  system  effects  are  minimized. 

Each  of  the  six  static  stability  forces  and  moments  for  the  mated  vehicle  and  its  four  elements 
are  formulated  in  this  manner.  The  forebody  coefficients  are  a function  of  the  freestream  Mach  number, 
the  vehicle's  orientation  to  the  freestream  flow  (a, 8),  and  the  elevon  deflection  angles  (Table  1). 

Math  modeling  of  the  elevon  effects  on  the  mated  vehicle  characteristics,  using  a fourth  order  poly- 
nomial fit,  has  been  incorporated  into  the  data  base  at  the  request  of  the  trajectory  and  guidance/ 
control  disciplines  to  facilitate  its  use.  The  element  data  are  provided  for  nine  discrete  inboard/ 
outboard  combinations.  Wing  and  vertical  tail  shear,  bending,  and  torsion  and  elevon  hinge  moments 
constitute  the  component  data.  These  are  formulated  similarly  to  the  element  data.  The  base  charac- 
teristics are  formulated  as  forces  and  moments  primarily  as  a function  of  altitude.  This  is  due  to 
their  first  order  dependency  on  the  plume  characteristics,  which,  for  a given  nozzle  and  engine  operat- 
ing characteristics,  are  primarily  a function  of  altitude.  However,  math  modeling  has  been  incorporated 
to  account  for  the  small  effects  due  to  vehicle  attitude  and  SSME  power  level  changes.  This  methodology 
formulation  allowed,  early  in  the  Shuttle  program,  determination  of  a quality  data  base.  Then,  as 
forebody  configurational  changes  took  place,  the  plume  technology  data  base  matured,  and  plume-on 
facility  testing  capability  developed,  refinements  to  the  data  base  could  be  effected  without  regenerat- 
ing the  complete  data  base. 

Two  types  of  uncertainties  were  generated  for  the  launch  vehicle  data  base  — tolerances  and  varia- 
tions. These  uncertainties,  although  not  statistically  derived,  were  generated  as  three-sigma  incre- 
mental values  with,  in  general,  a normal  distribution  about  the  nominal  data  base.  The  tolerances,  or 
lower  uncertainty  bounds,  represent  a measure  of  the  experimental  wind  tunnel  test  data  scatter  about 
the  established  nominal  data  base.  Tolerances  were  utilized  in  the  Shuttle  program  for  operational 
subsystem  design.  Variations,  or  upper  uncertainty  bounds,  represent  the  potential  difference  between 
the  wind  tunnel  derived,  experimental  characteristics  and  the  actual  flight  vehicle  characteristics. 
Variations  were  utilized  in  the  Shuttle  program  as  constraints  in  the  flight  planning  activities. 
Ordinarily  variations  are  derived  by  employing  the  historical  flight  experience  of  a vehicle  similar 
to  the  one  being  designed.  No  vehicle  similar  to  the  Space  Shuttle  launch  vehicle  has  ever  flown. 
However,  vehicles  such  as  the  generic  lifting  bodies  and  high  altitude/high  speed  aircraft  are  similar 
to  the  reentering  orbiter.  The  orbiter  entry  aerodynamic  discipline  utilized  the  flight  experience  of 
these  vehicles  to  derive  "variations"  for  the  orbiter  entry  aerodynamic  data  base.  The  ascent  aero- 
dynamic community  utilized  the  orbiter  entry  variation-to-tolerance  ratio  along  with  the  established 
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launch  vehicle  element  tolerances  to  establish  the  launch  vehicle  variations.  Both  tolerance  and  varia- 
tion uncertainties  were  generated  for  each  totally  independent  forebody  force,  moment  couple,  and  aero- 
dynamic center  coefficient  for  each  component  and  element  of  the  launch  vehicle.  This  permitted  deter- 
mination of  the  total  moment  uncertainty  for  each  component  and  element  as  the  root-sum-square  (RSS)  of 
these  three  independent  contributors.  The  mated  vehicle  uncertainties  were  established  as  the  RSS  of 
each  element fs  uncertainty.  The  base  characteristic  uncertainties  were  likewise  independent  and 
combined  in  an  RSS  fashion  with  the  forebody  uncertainties.  Analytical  modeling  was  formulated  to  allow 
assessment  of  a single  coefficient  uncertainty  or  any  combination  of  coefficient  uncertainties  by  any 
subsystem  discipline. 


SRB  SEPARATION  AERODYNAMIC  DATA  BASE 

The  Shuttle  Solid  Rocket  Boosters  (SRBs)  are  separated  at  burnout  from  the  launch  vehicle  by  means 
of  two  basic  phenomena.  Longitudinal  separation  is  achieved  as  a result  of  the  higher  axial  acceleration 
of  the  orbiter/external  tank  (OET) . Lateral  and  normal  separation  are  achieved,  however,  by  the  applica- 
tion of  thrust  to  the  SRBs  and  aerodynamic  forces.  Unlike  previous  cylindrical  launch  vehicles,  control 
of  these  nonlongitudinal  forces  is  critical  to  assure  that  no  recontact  occurs.  This  criticality  mani- 
fested itself  in  the  aerodynamicist * s ability  to  model  three  aerodynamic  phenomena:  (1)  the  proximity 
effect  of  one  vehicle ?s  flowfield  on  those  of  nearby  vehicles,  (2)  the  jet  interaction  effect  of  the 
BSM  plumes  on  the  flowfield  surrounding  all  of  the  vehicles,  and  (3)  the  effect  of  direct  BSM  plume 
impingement  on  the  external  tank.  Each  of  these  phenomena  is  a function  of  the  orientation  of  the  OET 
with  respect  to  the  free  stream  flow  and  the  relative  displacements  and  orientations  between  the  vehicles. 
The  jet  interaction  and  plume  impingement  effects  are  also  a function  of  a plume  scaling  parameter. 

This  knowledge  defined  the  set  of  eight  independent  parameters,  the  effects  of  which  had  to  be  con- 
sidered in  deriving  the  separation  data  base  (Fig.  9).  The  effects  of  Mach  number  and  Reynolds  number 
were  found  to  be  second  order  in  the  range  of  anticipated  flight  conditions  and  were  thus  included  in 
;he  data  base  uncertainty.  To  preclude  the  necessity  of  updating  the  complete  data  base  each  time  the 
vehicle  outer  moldline  was  changed,  the  dependent  variables  (aerodynamic  coefficients)  were  formulated 
as  BSM  plume-on  and  plume-off  proximity  increments;  that  is,  coefficient  increments  to  be  added  to  SRB 
and  OET  free-stream  aerodynamic  data.  Utilizing  this  approach  would  allow  the  effects  of  minor  con- 
figuration changes  to  be  adequately  reflected  in  updates  to  the  isolated  aerodynamics  with  negligible 
effects  on  the  proximity  increments. 

It  became  obvious  that  the  use  of  eight  independent  variables  in  the  data  base  would  present  severe 
difficulties  if  a standard  square  grid  of  representation  was  utilized  in  modeling  the  required  aero- 
dynamic characteristics.  The  most  obvious  difficulty  would  be  the  number  of  data  points  required.  The 
squareness  of  the  grid  in  8-dimensional  space  would  also  assure  that  most  of  the  data  points  would  be 
far  removed  from  areas  of  interest.  In  fact,  many  data  points  would  be  required  in  locations  that  are 
unrealizable  due  to  physical  constraints  imposed  by  the  basic  configuration.  Obviously,  superimposing 
the  large  matrix  of  proximity  variables  required  at  a large  AX  on  AX  * 0 would  be  unrealizable  since 
the  AX  * 0 position  constitutes  the  mated  position  of  the  SRB's  where  the  other  variables  can  only  have 
the  value  of  zero.  As  with  the  launch  vehicle  data  base,  consideration  also  had  to  be  given  to  the  wind 
tunnel,  the  basic  source  of  the  aerodynamic  data.  Limitations  on  specific  combinations  of  the  independ- 
ent parameters  AX,  AY,  AZ,  Aa,  AB  were  imposed  by  physical  constraints  of  the  facility  and  its  model 
mounting/ sting  movement  capability. 

These  difficulties  were  circumvented  by  developing  a unique  data  organization  concept  to  handle  the 
five  proximity  independent  variables.  This  new  approach,  designated  the  "hypercube"  format,  allows  data 
to  be  placed  only  along  required  separation  paths.  At  each  desired  AX  two  4-dimensional  hypercubes  are 
situated  so  as  to  encompass  anticipated  dispersions  in  AY,  AZ,  Aa,  and  A8.  An  outer  cube  encompasses 
all  dispersions,  including  system  failures,  while  an  inner  cube  includes  the  nominal  separation  path 
with  3a  dispersions.  These  hypercubes  are  not  constrained  to  have  parallel  opposite  sides  to  that  they 
can  be  shaped  to  match  physical  constraints  imposed  by  the  test  facility  and  still  provide  data  near  the 
required  trajectory  points  as  determined  by  trajectory  dispersion  analyses  (Fig.  10).  Data  points  were 
generated  at  the  vertices  of  the  hypercubes.  In  addition,  an  interior  point  is  placed  within  each 
hypercube  to  increase  the  data  density  in  a region  of  interest.  Typical  BSM  plume-on  SRB  trajectories 
through  the  hypercube  matrix  are  demonstrated  in  Figure  11  in  terms  of  the  parameters  AX,  AY,  and  AZ. 

The  AX  values  at  which  hypercubes  are  placed  were  selected  to  maintain  constant  time  increments  at  the 
separation  relative  longitudinal  acceleration  rather  than  constant  length  increments.  This  increases 
the  data  density  early  in  the  motion  when  trends  are  being  established. 

The  use  of  this  approach  has  provided  a much  higher  data  density  along  separation  trajectory  paths 
while  reducing  the  required  number  of  data  points  by  a factor  of  at  least  20  from  a square  grid.  A 
special  algorithm  has  been  developed  which  transforms  these  4-dimensional  arbitrary  shapes  into 
4-dimensional  cubes  so  that  a low  order  polynominal  can  be  easily  fit  to  the  vertices  and  interior 
point,  thus  providing  interpolation.  Interpolation  in  the  remaining  independent  variables  a,  8,  and 
the  plume  scaling  parameter  is  handled  in  a similar  manner,  although  the  organization  of  these  variables 
is  based  initially  on  3-dimensional  cubical  shapes  since  there  are  no  physical  interference  constraints 
to  be  taken  into  account. 
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The  uncertainties  associated  with  the  SRB  separation  aerodynamic  data  base  are  composed  of  three 
components:  an  error  resulting  from  the  hypercube  interpolation  process,  an  error  due  to  the  asymmetry 

of  the  motion  of  the  two  SRBs  with  respect  to  the  OET,  and  an  error  associated  with  scaling  the  BSM 
plumes.  The  uncertainty  component  associated  with  interpolation  error  accounts  for  the  inability  of  the 
hypercube  interpolator  polynomials  to  exactly  model  the  data  and  for  the  fact  that  the  data  base  was 
generated  at  a constant  value  of  Mach  number.  It  also  implicitly  accounts  for  the  random  uncertainty 
associated  with  the  wind  tunnel  data  measurements/acquisition  system.  The  uncertainty  component  asso- 
ciated with  asymmetric  SRB  motion  accounts  for  the  error  incurred  in  performing  all  plume-on  testing 
with  the  SRB's  in  symmetric  positions  with  respect  to  the  OET.  SRB  asymmetry  modifies  plume-on  aero- 
dynamics by  establishing  unequal  impingement  of  the  BSM  plumes  on  the  external  tank  and  by  causing  an 
asymmetric  interaction  of  the  plumes  with  the  free-stream  flow.  The  third  aerodynamic  uncertainty 
component  results  from  errors  in  plume  scaling,  that  is,  errors  incurred  by  using  the  jet-to-free  stream 
momentum  ratio  rather  than  the  momentum  flux  ratio  as  the  plume  simulation  parameter  (discussed  later). 
The  total  coefficient  uncertainties  in  the  data  base  were  obtained  by  root-sum-squaring  the  contribution 
of  these  three  components. 


CHALLENGE:  WIND  TUNNEL  TESTING  TECHNIQUES /IMPROVEMENTS 

The  primary  sources  of  the  Space  Shuttle  ascent  aerodynamic  data  base  are  wind  tunnel  test  results. 
The  multibody  configuration  with  its  significant  interrelated  interference  effects  precluded  using  con- 
ventional analytical  tools  to  characterize  the  vehicle.  Initial  wind  tunnel  tests  provided  results 
which  included  effects  from  model  support  structure,  inadequate  element  proximity,  and  inadequate  plume 
simulation.  It  became  obvious,  as  the  Shuttle  program  matured,  that  these  undesirable  effects  were 
significant.  The  challenge  to  improve  the  quality  and  detail  of  test  results  by  determining  the 
extent  of  these  effects,  and  subsequently  develop  testing  techniques  to  eliminate  them,  was  imposed  on 
the  aerodynamic  community.  In  the  process  of  establishing  the  ascent  aerodynamic  data  base  two  basic 
types  of  wind  tunnel  test  results  were  utilized.  Force  and  moment  data  were  obtained  by  using  balances 
located  in  the  models.  Data  of  this  type  were  obtained  for  the  mated  vehicle,  the  elements,  and  the 
components  for  the  launch  vehicle  data  base.  Data  of  this  type  were  also  obtained  for  the  SRBs  and  OET 
combination  in  proximity  for  the  SRB  separation  data  base.  The  other  type  of  data  obtained  from  testing 
were  local  pressure  distributions  (airloads  test)  over  the  entire  vehicle.  These  data  were  obtained  by 
locating  pressure  orifices  on  the  outer  moldline  of  the  model  and  recording  the  sensed  pressures. 

These  data  were  utilized  in  formulating  the  airloads  for  the  launch  vehicle  data  base.  As  mentioned 
earlier,  the  physical  limitations /complexity  of  the  models  did  not  permit  simultaneously  obtaining  all 
the  required  data  with  a single  model/test.  Therefore,  different  type  tests  were  conducted  and  their 
results  combined  to  generate  the  data  base.  Mated  vehicle/element  plume-off  force/moment  and  airloads 
test  results  were  combined  with  plume-on  mated  vehicle/element  airloads  test  results  to  obtain  the 
launch  vehicle  data  base.  The  SRB  separation  data  base  utilized  only  BSM  plume-on  and  plume-off 
force-moment  test  results.  Associated  with  each  of  the  above  type  tests  were  peculiar  generic  problems 
and  inadequacies  that  had  to  be  resolved  in  order  to  establish  a quality  data  base. 

LAUNCH  VEHICLE/ELEMENT/COMPONENT  PLUME-OFF  TESTS 

Initial  emphasis  was  placed  on  the  mated  vehicle  force/moment  aerodynamic  characterization.  To 
support  generating  the  required  data,  wind  tunnel  tests  utilizing  a single  sting  support  (Fig.  12) 
were  conducted.  The  elements  were  rigidly  mounted  to  each  other  with  scaled  attach  structures  thus 
preserving  the  required  proximity.  A single  balance  was  located  in  the  orbiter  which  measured  the  six 
aerodynamic  forces  and  moments  required  by  the  launch  vehicle  data  base.  This  single  sting/base  mount- 
ing arrangement  was  most  practical  and  provided  minimum  sting  effects  on  the  forebody  aerodynamic  data. 

As  the  Shuttle  program  matured  emphasis  shifted  to  defining  the  element  and  component  aerodynamic 
characteristics.  Wind  tunnel  tests,  designated  as  IA81  and  LA135,  were  conducted  in  the  Ames  Research 
Center  Unitary  Plan  Wind  Tunnel  (ARC  UPWT)  to  provide  aerodynamic  data  supporting  the  integrated  vehicle 
baseline  characterization  cycles  1 and  2 (IVBC-1  and  IVBC-2).  These  tests,  to  obtain  data  for  each  of 
the  elements  and  components  in  proximity,  utilized  a four-sting  model  support  system  (Fig.  13).  Each 
element,  which  contained  a balance  for  measuring  the  aerodynamic  forces  and  moments,  was  mounted  on  a 
separate  sting  in  proper  proximity  with  the  free-stream  air  off.  The  sting  and  balances  were  designed 
to  minimize  deflections  considering  model  weight  and  aerodynamic  load,  yet,  provide  adequate  measure- 
ment accuracy  in  terms  of  the  expected  aerodynamic  loads  on  the  model.  However,  with  freestream  air  on 
the  aerodynamic  loading  on  each  element  caused  excessive  model  separation.  Thus,  the  proper  inter- 
ference effects  of  the  elements  on  each  other  was  not  realized.  And,  furthermore,  each  element  was  at 
a different  attitude  relative  to  the  freestream  flow.  Additionally,  the  presence  of  the  ET  sting  and 
the  sting  support  created  an  effect  on  the  forebody  aerodynamics.  The  presence  of  these  effects  was 
implicitly  determined  when  the  summation  of  the  element  did  not  equal  the  mated  vehicle  data  obtained 
from  other  tests  utilizing  a single  sting  support  system.  The  presence  of  these  effects  was  further 
verified  by  a series  of  parametric  tests  conducted  in  the  Marshall  Space  Flight  Center’s  14-in.  Trisonic 
Wind  Tunnel.  The  significance  of  these  undesirable  effects,  except  from  a purist  standpoint,  were  of 
little  consequence  to  the  aerodynamist . However,  as  structural  load  sensitivity  studies  developed. 
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significant  impacts  of  small  changes  in  the  element /component  aerodynamics  on  the  vehicle fs  attach 
structure,  wing  design,  and  vertical  tail  design  were  realized.  Obviously,  the  undesirable  effects  in 
the  aerodynamic  data  base  needed  to  be  eliminated  if  possible,  rather  than  incorporate  them  into  uncer- 
tainties on  the  data. 

To  eliminate  the  above  undesirable  effects  the  ascent  aerodynamic  community  and  wind  tunnel  model 
designers  established  the  "shell  model"  concept  for  Space  Shuttle  testing  (Fig,  14).  This  concept 
offered  two  distinct  advantages  over  previous  model  designs:  (1)  only  a single  sting  support  is 

required,  thus  eliminating  the  majority  of  the  sting  interference  effects,  and  (2)  permits  measuring 
the  element  data  simultaneously  with  the  mated  vehicle  data,  thus  ensuring  that  the  summation  of  the 
element  aerodynamic  data  equals  the  mated  vehicle  aerodynamic  data.  This  is  achieved  by  utilizing  a 
balance  in  each  element  and  specific  attachment  of  the  element fs  outer  moldline  (OML)  shells  to  each 
other  via  the  scaled  attach  structures.  This  permits  each  balance  to  measure  aerodynamic  loads 
experienced  by  certain  combinations  of  elements  (i.e.,  the  SRB  balances  measure  SRB  aerodynamics,  the 
ET  balance  measures  ET  and  SRB  aerodynamics,  and  the  orb iter  balance  measures  the  mated  vehicle  aero- 
dynamics). Thus  each  element’s  aerodynamic  characteristics  are  obtained  directly  through  measurement 
(SRBs)  or  by  subtracting  appropriate  balance  results  (orbiter  and  ET) . This  shell  model  concept  was 
pilot  tested  using  a 1 percent  scale  model  in  the  ARC  UPWT,  and  later  utilized  with  a 2 percent  model 
(Fig.  15)  in  the  16T  Propulsion  Wind  Tunnel  facility  at  the  Arnold  Engineering  Development  Center  (AEDC) 
to  provide  a large  part  of  the  power-off  data  base  for  STS-1. 

To  eliminate  the  remaining  potential  sting  interference  effects  on  the  orbiter  forebody  aerodynamic 
characteristics  an  additional  model  was  designed  utilizing  the  "shell  model"  concept  (Fig.  16).  This 
3 percent  scale  model  was  supported  by  two  stings  through  the  base  of  each  SRB  and  utilized  a single 
balance  in  the  orbiter  to  determine  the  orbiter  aerodynamic  characteristics.  The  orbiter  was  mounted 
as  a shell  model  to  the  ET/SRB  combination  via  the  scaled  attach  structure.  This  model  was  also 
utilized  to  determine  the  power-off  pressure  distributions  on  the  vehicle.  The  orbiter  balance  was 
removed  and  the  complete  vehicle  instrumented  with  approximately  1,500  pressure  orifices.  This  model 
was  also  tested  at  the  AEDC  16T  facility  and  the  results  constitute  the  remaining  part  of  the  power-off 
data  base  for  STS-1. 


LAUNCH  VEHICLE/ELEMENT/COMPONENT  PLUME-ON  TESTS 

Early  in  the  Shuttle  program  it  was  anticipated  that  the  exhaust  plumes  from  the  SSME/SRB  engines 
would  affect  the  aerodynamic  characteristics  of  the  vehicle.  This  was  based  on  the  history  of  rocket- 
powered  launch  vehicles  and  the  resulting  plume  effect  phenomena  that  was  developed  over  the  years. 

This  phenomena  is  philosophically  demonstrated  in  Figure  17.  For  a given  engine/rocket  motor  operating 
at  a fixed  altitude  and  Mach  number  the  exhaust  plume  phenomena  vary  with  increasing  rocket  engine 
chamber  pressure.  The  plume  diameter  is  initially  too  small  to  significantly  alter  the  forebody 
pressure.  Thus,  the  primary  effect  is  the  entrainment  of  the  base  flow  by  the  high  velocity  gases  in 
the  boundary  of  the  plume  and  the  subsequent  reduction  of  power-off  base  pressure.  As  the  plume  grows 
in  size,  it  begins  to  block  the  base  and  increase  the  base  pressure.  Ultimately,  the  boundary  layer 
will  separate,  and  a recirculating  pattern  will  develop.  For  multiple  engines,  the  plumes  will  impinge 
upon  each  other  and  deflect  exhaust  flow  into  the  base.  Three  or  more  engines  can  reverse  enough  mass 
into  the  base  to  choke  the  volume  enclosed  by  the  engines.  The  effect  of  the  plumes  can  actually 
increase  base  pressure  above  the  power-off  level. 

To  simulate  the  plumes  and  their  effect  in  wind  tunnel  testing  the  ascent  aerodynamics  community 
had  three  basic  design  options  available:  (1)  hot  gas  by  combustion,  (2)  cold  or  warm/heated  gas,  and 

(3)  solid  body  simulators.  Hot  gas  testing  was  eliminated  as  a viable  option  when  cost  and  complexity 
were  considered.  Additionally,  the  data  quality  for  hot  gas  testing  is  limited  extensively  because  of 
the  short-duration  of  steady  state  flow.  The  use  of  a solid  body  simulator  was  also  eliminated  from 
consideration.  Since  the  base  environment  was  not  known  before  testing,  the  configuration  of  the  plume 
shape  could  not  be  determined  to  enable  design  of  the  solid  body.  Historically,  cold  gas  testing  had 
been  used  almost  exclusively  for  launch  vehicle  plume  simulation.  A cold  gas  model  can  continuously  be 
operated  to  obtain  70  to  100  data  points  per  shift  in  the  test  facility.  Therefore,  the  Space  Shuttle 
Program  Office  chose  this  technique  to  determine  launch  vehicle  plume  effects  because  of  cost  and 
schedule  effectiveness. 

In  1972,  NASA  initiated  the  planning  phase  for  the  first  wind  tunnel  test  of  the  Space  Shuttle 
launch  vehicle  (SSLV) . At  this  time,  the  technical  archives  were  surveyed  to  determine  the  appropriate 
rocket  exhaust  simulation  techniques.  The  data  accumulated  through  experience  with  the  Saturn  launch 
vehicle  were  chosen  for  study.  A comparison  of  the  wind  tunnel  predictions  with  the  Saturn  flight  data 
indicated  a deficiency  in  the  technology  at  that  time.  The  base  drag  was  substantially  overestimated 
by  the  predictions  from  wind  tunnel  testing.  The  surveys  concluded  that  the  simulation  techniques  and 
the  simulation  parameters  were  not  well  understood.  Therefore,  the  aerodynamic  community  was  challenged 
to  better  understand  the  flow  phenomena  and  develop  a set  of  simulation  parameters  for  use  in  wind 
tunnel  testing  of  the  Space  Shuttle  launch  vehicle.  To  this  end  a plume  technology  program  was 
initiated  by  NASA. 
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The  objective  of  the  technology  program  was  to  determine  a set  of  functions  that  would  correlate 
base  pressure  data  generated  by  wind  tunnel  cold  gas  tests  with  full  scale  flight  base  pressure.  An 
empirical  data  base  was  obtained  using  generic  models  with  some  geometry  variations  to  assess  configura- 
tion effects  on  the  base  pressure.  The  key  independent  variables  were  simulated  gas,  nozzle  geometry, 
and  geometric  configuration.  Hot,  warm,  and  cold  gases  were  used.  Simulated  model  nozzle  area  ratios 
and  nozzle  lip  angles  varied  from  test  to  test,  assuring  that  internal  geometry  was  not  an  explicit 
contributor  to  the  correlation  functions.  The  external  configurations  consisted  of  cone  or  ogive  noses 
and  cylindrical  afterbodies  with  single  or  triple  nozzle  bases  (SRB  and  orbiter  bases  respectively); 
and,  a triple  body  configuration  to  assess  the  effects  on  a centerbody  (similar  to  the  external  tank  on 
the  Space  Shuttle).  Because  difficulties  were  encountered  in  correlating  the  plume  technology  test  data 
due  to  limited  variations  in  nozzle  geometry  and  test  conditions,  analytical  tools  were  utilized  to 
supplement  the  data  base. 


The  substantial  empirical  and  analytical  data  base  generated  throughout  this  technology  program 
was  then  analyzed  for  correlation  by  plotting  the  base  pressure  data  as  a function  of  reasonable  can- 
didate simulation  parameters.  The  successful  simulation  parameters  were  those  that  would  coalesce  the 
base  pressure  data  to  a simple  function  of  the  assumed  simulation  parameter.  As  the  technology  program 
developed,  the  plume  simulation  correlation  parameters  matured  from  the  simple  parameters  defining  plume 
shape  to  a function  based  on  shape  and  gas  dynamic  characteristics.  The  final  simulation  parameter 
developed  through  the  technology  program  has  the  form: 


M.  6. 
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This  final  "winning"  set  of  simulation  parameters  is  demonstrated  in  Figure  18  along  with  a definition 
of  terms.  The  caveat,  however,  is  that  neither  the  hot  gas  technology  test  nor  the  hot  gas  analytical 
data  agree  with  this  simulation.  In  other  words,  this  simulation  correlated  the  cold/warm  gas  data  but 

an  apparent  temperature  function,  (Tc/Tt  )C,  needed  to  be  included  to  fully  correlate  the  data.  These 

00 

data  came  too  late  to  impact  any  Space  Shuttle  testing  prior  to  the  first  flight  due  to  program 
schedule  and  resource  restrictions.  However,  indications  were  that  the  exclusion  of  the  temperature 
function  would  result  in  an  overprediction  of  the  flight  base  drag  and,  consequently,  an  underestimate 
of  vehicle  performance  resulting  in  a conservative  design.  The  current  status  of  the  technology  program 
is  best  described  as  "terminated  incomplete."  The  technology  program,  however,  yielded  substantial 
knowledge  on  how  to  correlate  the  cold  gas  base  pressure  and,  therefore,  advanced  the  state-of-the-art. 

Not  only  did  the  definition  of  the  simulation  parameters  have  to  be  addressed,  but  also  the  applica- 
tion of  the  required  simulation  in  the  wind  tunnel  had  to  be  established.  Unfortunately,  the  key  to  the 
technique  of  base  pressure  correlation  is  that  the  simulation  parameters  are  a function  of  the  base 
pressure  itself.  For  example,  6 and  M.  are  dependent  on  the  Prandtl-Meyer  expansion  at  the  nozzle  lip 
and,  therefore,  proportional  to  the  base  pressure  and  the  square  root  of  the  base  pressure,  respectively. 
Consequently,  if  the  base  pressure  is  not  known  a priori,  the  correct  simulation  in  the  wind  tunnel  is 
impossible  to  establish.  The  technique  that  evolved  from  the  plume  technology  program  and  the  early 
SSLV  tests  to  circumvent  this  problem  is  as  follows: 

1.  Model  nozzles  are  designed,  using  analytical  tools,  to  provide  a range  of  similarity  parameters 
for  a test. 


2.  For  a fixed  Mach  number,  a variation  of  the  base  pressure  is  obtained  through  a variation  of 
the  model* s SSME  and  SRB  chamber  pressures  via  the  auxiliary  high  pressure  air  supply. 

3.  The  variation  of  the  base  pressure  from  the  wind  tunnel  test  is  plotted  as  a function  of  the 
simulation  parameter.  See  curve  A in  Figure  19. 

4.  A similar  curve  can  be  analytically  derived  for  the  full  scale  prototype  by  assuming  a base 

pressure  (curve  B,  Fig.  19).  This  curve  represents  the  loci  of  possible  values  of  the  similarity 

parameters  for  the  prototype  as  a function  of  base  pressure. 

5.  Where  the  curve  of  prototype  possibilities  is  equal  to  the  wind  tunnel  test  data,  the  similar- 
ity is  matched,  and  the  resulting  base  pressure  is  the  design  value. 

The  SSLV  test  data  were  acquired  in  the  ARC  UPWT.  This  facility  developed  the  capability  to  supply 

secondary  air  flow  at  a rate  of  1500  psi  and  80  lb/sec  for  Shuttle  propulsion  system  simulation.  In 

Figure  20  the  model  is  shown  installed  in  the  UPWT  11-ft  test  section.  Note  the  model  support  structure 
required  to  supply  the  high  pressure  air  for  plume  simulation  and  an  enclosure  for  the  instrumentation 
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leads  from  the  model.  As  mentioned  earlier,  this  support  structure,  due  to  its  interference  effects  on 
the  forebody,  dictated  that  only  incremental  effects  of  the  plumes  could  be  utilized.  Balances  were 
utilized  in  the  orbiter  wing,  elevons,  and  vertical  tail  to  provide  incremental  force /moment  data  for 
the  components.  Additionally,  the  entire  vehicle  was  instrumented  with  pressure  orifices  to  provide 
the  incremental  plume  effects  on  the  pressure  distributions.  The  results  from  this  type  test  were  com- 
bined with  plume-off  data,  determined  from  other  tests,  providing  a complete  plume-on  launch  vehicle 
data  base. 


SRB  SEPARATION  TESTS 

Basic  wind  tunnel  testing  of  separating  bodies  was  recognized  as  a complex  operation  early  in  the 
Shuttle  program.  In  fact,  if  the  bodies  have  significantly  different  flight  path  angles,  wind  tunnel 
testing  cannot  be  performed  to  adequately  simulate  the  combined  flowfield  of  the  bodies.  This  is 
because  the  wind  tunnel,  with  its  inherent  axial  flow,  provides  only  a single  fixed  flight  path  angle 
for  all  bodies.  The  addition  of  booster  separation  motor  (BSM)  plume  simulation  further  complicated 
the  testing  by  providing  a high  energy  disturbance  to  the  flowfield.  Fortunately,  the  SRB  flight  path 
angle  was  not  significantly  different  from  the  Orbiter /ET  flight  path  angle  during  the  initial  phases 
of  separation.  Therefore,  the  error  in  attitude  and  consequent  flowfield  development  was  small  and 
represented  no  stumbling  block  to  SRB  separation  testing.  However,  determining  the  correct  BSM  plume 
simulation  to  provide  the  required  vehicle  flowfield  and  plume  impingement  effects  on  the  OET  repre- 
sented a challenge  to  the  aerodynamicist . 

The  requirement  of  correct  BSM  simulation  manifests  itself  in  the  need  to  simulate  the  near-field 
jet  interaction  (JI)  effects  on  the  SRB  aerodynamic  characteristics,  and  the  need  to  simulate  the  far- 
field  spacial  content  of  the  plume  (jet)  impingement  forces  on  the  OET  (Fig.  21).  Early  in  1973  the 
planning  for  the  first  SRB  separation  test  was  initiated.  At  this  time  a literature  survey  was  con- 
ducted to  retrieve  all  possible  information  relative  to  the  effects  of  jet  emission  normal  to  freestream 
flow.  The  results  of  the  survey  indicated  that  the  similarity  parameter  for  near-field  simulation  of  a 

transverse  firing  single  jet  was  the  ratio  of  jet-to-freestream  momentum  flux,  q*. /q" . Plume  interaction 

J 00 

with  a freestream  crossflow,  as  depicted  in  Figure  22,  was  then  defined  by  the  following  empirical  rela- 
tionship for  Mach  disk  height: 
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The  far-field  jet  impingement  pressure  similarity  parameters  were,  intuitively,  momentum  flux  ratio  and 
plume  diameter  at  the  point  of  impingement  some  distance  from  the  jet  (Fig.  22). 

It  was  also  found  that  plume  gas  temperature  and  molecular  weight  affect  jet/f lowf ield  interaction 
by  strongly  influencing  the  external  flow  separation  distance  upstream  of  the  nozzle  for  low  molecular 
weight  or  high  temperature  transverse  jets.  This  effect  is  correlated  by  the  "RTM  ratio  as  follows: 

_ (RTo)j  = (To/MW) j 
(RT)„  (T/MH)^ 


"RT"  simulation  provided  the  rationale  for  using  air  as  the  injectant  gas  in  wind  tunnel  plume  testing. 
Findings  from  the  survey  indicated  that  "RT"  effects  are  negligible  for  x < 7.  Since  the  values  for 
flight  (x  = 2.91)  and  test  with  air  (x  = 4.6)  are  below  this  limit,  unheated  air  was  selected  to  simu- 
late the  BSM  exhaust  product  plume. 

Even  though  these  similarity  parameters  were  developed  from  single  jet  data,  they  were  utilized 
for  the  multijet  case  in  the  early  phases  of  SRB  separation  testing.  At  this  stage  of  separation  system 
development,  the  BSM  configuration  was  four  motors  in  line  rather  than  abreast  as  shown  in  Figure  5. 

The  forward  motors  were  located  further  aft  (SRB  forward  skirt)  and  the  rear  motor  exit  planes  pointed 
toward  the  orbiter  body  flap  rather  than  in  an  aft  direction.  Their  angular  orientation  directed  the 
plumes  more  toward  the  orbiter  than  the  final  configuration  shown  in  Figure  5 (i.e.,  30  deg  and  20  deg 
rather  than  20  deg  and  40  deg,  respectively).  Results  from  these  tests  indicated  significant  flowfield 
changes  and  impingement  pressures  on  the  sensitive  orbiter  TPS  tiles.  To  verify  and  expand  the  findings, 
analytical  tools  were  utilized  to  reproduce  the  test  generated  plume  characteristics  and  a separation 
motor  technology  program  was  initiated  at  the  Marshall  Space  Flight  Center.  The  technology  program 
verified  the  simulation  parameters  and  added  insight  into  the  relationship  between  the  flowfield  of 
single  jets  and  mutliple  jets.  Utilizing  the  developed  analytical  tools,  sensitivity  studies  were 
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performed  for  various  alternate  BSM  configurations  and  orientations  in  an  effort  to  relieve  the  impinge- 
ment effects  on  the  orbiter.  The  final  BSM  orientation  (Fig.  5)  resulted  from  these  studies.  Along 
with  the  relocation/orientation  of  the  BSMs  their  thrust  was  increased  and  burn  time  decreased.  This 
reduced  the  time  that  the  massive  complex  jet/f lowf ield  interaction  would  take  place  and  still  provide 
adequate  impulse  to  the  SRB  to  avoid  recontact. 


As  plans  for  testing  of  the  final  BSM  configuration  developed,  it  was  realized  that  scaling  q^/q^ 

was  no  longer  possible.  The  increased  thrust  required  a plume  gas  air  supply  pressure  (1500  psi)  that 
exceeded  the  facility's  capability  and  the  small  nozzle  sizes  required  (1/32-in.  throat  diameter) 
became  prohibitive.  As  a result,  jet-to-freestream  momentum  ratio  (<Pj/4m)  was  selected  over  q^/^  as 

the  plume  scaling  parameter.  This  choice  preserved  the  geometric  scaling  of  h^  but  removed  any 
dependence  on  nozzle  size,  d ^ : 
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Using  momentum  ratio  scaling,  nozzle  throat  size  was  doubled  to  minimize  the  chance  of  nozzle  plugging 
(a  problem  encountered  in  early  testing)  and  the  chamber  pressure  was  reduced  to  within  plant  gas 
supply  limits.  Model  nozzle  area  ratio  was  adjusted  to  obtain  a good  match  of  plume  cross-sectional 
area  and  hence  proper  simulation  of  the  blockage  associated  with  f lowf ield  interaction  effects. 
Utilizing  the  momentum  ratio  similarity  parameter  induced  errors  into  the  wind  tunnel  test  results. 
However,  an  estimate  of  the  uncertainty  in  SRB  aerodynamic  characteristics  was  appropriately  evaluated 
by  comparing  test  and  flight  data  available  from  a military  missile  which  utilized  a transverse  jet  for 
attitude  control.  These  uncertainties  were  included  in  the  separation  aerodynamic  data  base. 


All  testing  used  to  define  the  SRB  separation  aerodynamic  data  base  was  conducted  in  the  U.S.  Air 
Force  Arnold  Engineering  Development  Center /Von  Karman  Facility  Tunnel  "A"  using  a 1 percent  scale 
model  of  the  Space  Shuttle  vehicle.  This  facility  was  selected  because  of  its  efficient  captive 
trajectory  system  (CTS)  which  provides  rapid  computerized  movement  of  models  in  the  tunnel  without 
interrupting  the  primary  tunnel  air  flow. 

In  BSM  plume-on  testing,  the  orbiter/ET  was  placed  on  the  CTS  sting  and  the  two  SRBs  were  placed 
on  a specially  designed  screw-jack  adapter  to  the  primary  sting.  This  adapter  allowed  automatic  move- 
ment of  the  SRBs  in  the  yaw  plane  but  required  manual  placement  in  pitch.  The  BSM  plume-on  test 
installation  is  shown  in  Figure  23a.  Separate  lines  were  provided  to  supply  plume  air  to  plenum 
chambers  for  the  forward  and  aft  nozzle  clusters  in  each  SRB.  The  forward  clusters  were  fed  by  air 
flowing  through  the  balances.  Care  was  taken  to  balance  the  plenum  chamber  pressures  between  forward 
and  aft  jets  and  between  left  and  right  SRBs  by  means  of  orifice  meters  in  the  individual  supply  lines. 
In  plume-on  testing,  previous  experience  has  shown  that  it  is  necessary  to  account  for  SRB-to-SRB  BSM 
plume  induced  flow  interference  as  well  as  for  the  mutual  coupling  of  the  SRBs  plume  interference 
effects  on  the  f lowf ield  surrounding  the  OET.  Hence,  the  use  of  both  SRBs  is  required. 

In  plume-off  testing,  a single  SRB  was  mounted  on  the  CTS  and  moved  through  the  hypercube  matrix 
of  points  representing  relative  positions  and  attitudes  of  the  SRB  with  respect  to  a fixed  OET.  The 
model  installation  is  shown  in  Figure  23b.  Although  forces  and  moments  were  measured  on  both  models, 
axial  force  and  rolling  moment  were  not  measured  on  the  SRB.  The  SRB  model  was  equipped  with  a flow- 
through balance  for  use  in  plume-on  testing  making  it  impossible  to  measure  axial  force  with  any  degree 
of  accuracy.  Rolling  moment  was  also  eliminated  from  the  balance  readings  since  it  is  negligible  as  a 
result  of  SRB  body  symmetry.  Previous  plume-off  test  experience  indicated  that  SRB-to-SRB  effects  are 
minimal  and  that  SRB  effects  on  the  orbiter/ET  are  additive,  thus  justifying  the  use  of  a single  SRB 
test  procedure. 


The  final  SRB  separation  verification  test  was  conducted  at  AEDC  in  March  1982  and  provided  the 
data  for  the  current  data  base.  This  test  culminated  a complex  wind  tunnel  test  program  to  define  the 
aerodynamics  associated  with  SRB  separation. 


CONCLUDING  REMARKS 


The  challenges  to  the  ascent  aerodynamic  community  documented  in  this  paper  are  unique  due  to  the 
aerodynamic  complexity  of  the  Shuttle's  ascent  flight.  Never  before  has  such  a complex  vehicle  been 
aerodynamically  characterized. 

The  initial  optimization  challenge  was  met  by  providing  a parametric  aerodynamic  data  base  which 
allowed  configuration  optimization  from  an  aerodynamic  standpoint. 


159 


The  challenge  to  aerodynamically  characterize  the  vehicle  with  math  modeling  methodologies  to 
support  vehicle  design  and  flight  planning  studies  was  innovatively  met.  Techniques  for  combining  the 
results  of  several  wind  tunnel  tests  were  developed  which  minimized  model  support  system  effects  in  the 
launch  vehicle  data  base.  A unique  and  effective  modeling  approach  was  developed  to  handle  the  large 
and  complex  SRB  separation  aerodynamic  data  base. 

The  challenge  to  develop  testing  techniques  to  improve  the  quality  of  initial  wind  tunnel  test 
results  was  successfully  met.  Parametric  wind  tunnel  tests  and  analyses  were  conducted  to  determine 
model  support  system  effects  on  vehicle  aerodynamics.  The  resulting  optimum  models  and  support  system 
were  designed  and  utilized.  Comprehensive  plume  technology  programs  were  conducted  which  established 
simulation  parameters  permitting  the  use  of  high  pressure  air  to  simulate  engine  exhaust  plumes  and 
high  energy  forward  facing  jet  effects. 

The  unique  and  innovative  engineering  approaches/ techniques  developed  to  meet  the  aerodynamic 
challenges  imposed  by  the  complex  Shuttle  configuration  and  ascent  flight  have  resulted  in  quality 
aerodynamic  data  bases.  The  success  of  the  Shuttle  ascent  aerodynamic  development  program  is  exempli- 
fied by  the  successful  STS  program. 
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SYMBOLS  SUBSCRIPTS 


A 

Area 

A 

Axial  force 

x,y,z 

Displacement  of  SRB 

C 

Coefficient 

B 

Base;  bending  moment 

from  mated  position 

d 

diameter 

C 

Chamber 

(co) 

Freestream 

hiD 

Jet  Mach  disk  height 

E 

Exit 

M 

Mach  number 

e 

Elevon 

MW 

Molecular  weight 

f 

Forebody 

SUPERSCRIPTS 

R 

Universal  gas  constant 

H 

Hinge  moment 

a,b,c 

Undetermined  expon- 

q 

Dynamic  pressure 

i 

Inboard  elevon 

ents,  functions  of 
geometric  configura- 

SREF 

Reference  area 

j 

Plume  boundary 

tion 

T 

Temperature 

1 

Rolling  moment 

a 

Angle-of-attack 

m 

Pitching  moment 

8 

Angle-of-sideslip 

n 

Yawing  moment 

r 

Ratio  of  specific  heats 

N 

Nozzle 

6 

Initial  expansion  angle  of  gas 

0 

Outboard  elevon 

0 

Lip  angle 

P 

Pressure 

A 

incremental  value 

S 

Shear  force 

<P 

Momentum 

t 

Torsion  moment 

V 

Vertical  tail 

w 

Wing 

Y 

Side  force 
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TABLE  Is  LAUNCH  VEHICLE  AERODYNAMIC  DATA  BASE  FORMULATION 


TYPE  OF  DATA 

FORMULATION 

MATED  VEHICLE  F0REB0DY 
STATIC  STABILITY 

o MACH  = 0.6,  0.8.  0.9,  0.95,  1.05,  1.10,  1.15,  1.25,  1.40, 
1.55,  1.80,  2.2,  2.5,  3.5,  4.5 

o a/8  = -8°  + +4°/-6°  + +6°,  A = 2° 

o ELEVON  SETTINGS  = MATH  MODELED  VIA  4TH  ORDER  POLYNOMIAL 
FIT  OF  DATA  VARIATIONS  WITH  INB'D  & OUTB'D  SETTINGS. 

ELEMENT  F0REB0DY 
STATIC  STABILITY 
(ORB,  ET,  LSRB, 
RSRB) 

o MACH  = SAME  AS  ABOVE 
o a/8  = SAME  AS  ABOVE 

o ELEVON  SETTINGS  = 9 DISCRETE  INB'D/OUTB'D  COMBINATIONS 
FOR  EACH  MACH. 

COMPONENT  STATIC 
STABILITY 
(WING,  ELEV0NS, 
V.  TAIL) 

SAME  AS  FOR  ELEMENTS 

POWER-ON  BASE 
FORCE/MOMENT 
(ORB,  ETC,  LSRB, 
RSRB) 

o ALT  = 0 = 200,000  FEET 

o MATH  MODELING  INCLUDED  TO  ACCOUNT  FOR  a/ 6 AND  SSME 
POWER  LEVEL  EFFECTS 

ELEMENT /COMPONENT 
PRESSURE  DISTRIBUTIONS 

o SAME  AS  FOR  ELEMENTS /COMPONENTS  ABOVE 
o Cp  * f(x,y,z,<j>) 

SOLID  ROCKET  \ 
BOOSTERS 


CONFIGURATION 


VEHICLE 


ORBITER 


LOCATION 

AND 

INCIDENCE 


DESIGN 

EFFECTS 


EXTERNAL 

TANK 


SIZE  AND 
NOSE  SHAPE 


SIZE,  LOCATION 
AND 

NOZZLE  DESIGN 


ATP 

(3/4/72) 


•972  IN.  AFT 
OF  ETNOSE 
•-1.2°  INCID. 


• STRAIGHT 
WING  T.  E. 


• 318  IN  DIA 

•30°  NOSE 
CONE 


• 156  IN.  DIA. 

•SRB  NOSE  FWD. 

OF  ET  SHOULDER 

• LARGE  CANT 
NOZZLE 

• NO  TVC 


PRR 

(10/24/72) 
MCR  0026 


1063  IN  AFT 
OF  ETNOSE 
+0.5°  INCID. 


• ASRMS 
REMOVED 

• OMS  PODS 
MOVED 

TO  SHOULDER 

• SWEPT  T.  E. 


•304  IN.  DIA 

• OGIVE 
NOSE 
W/RETRO 
PKG. 


• 162  IN.  DIA 

• SRB  NOSE  AT 
ET  SHOULDER 

• PRE-CANT  REDUCED 

• TVC  ADDED 


< 


<E 


2A 

(12/22/72) 
MCR  0074 


•768  IN.  AFT 
OF  ET  NOSE 


• INCREASED 
NOSE  RADIUS 


• 324  IN.  DIA 


• 142  IN.  DIA. 

• SRB  AFT  OF 
ET SHOULDER 

•REDUCED  AFT  SKIRT 
FLARE 

• NO  PRE-CANT 


3,  3A 

MCR  0200 
(5/73) 


► 680  IN.  AFT 
OF  ET  NOSE 


• REDUCED 
WING  INCID. 

• BODY  38  IN 
SHORTER 

• DECREASED 
NOSE 
RADIUS 


•324  IN.  DIA 


•REMOVED 

RETRO 


• 142  IN.  DIA. 

• DECREASED  AFT 
SKIRT  SIZE 

• 7:1  NOZZLE 

• INLINE  SEP.  MTRS. 


C 


<E 


4,  5 

MCR  3570 


• BLUNT  OMS 
PODS 


• UNCOVERED 
RCS PORTS 


•333  IN.  DIA, 


•BICONIC 

AADS 


• ATTACH  RING 
AREA  REDUCED 

• ELIMINATED  2 
OF  THE  4 HOOP 
STRESS  RINGS 

• 4 ABREAST  SEP 

MTRS. 


Figure  1.  Space  Shuttle  Design  Evolution. 
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FOREBODY  AXIAL  FORCE  FOREBODY  AXIAL  FORCE 

COEF . (CAf  _ q)  £ COEF.  (cAfa  _ q) 


REF:  MSFCTWT556 
CONFIG:  ATP  BASELINE 


HI 


MACH  NUMBER  (Moo) 


EFFECT  OF  ET  NOSE  SHAPE  ON 
LAUNCH  VEHICLE  AXIAL  FORCE 


REF:  MSFCTWT570 
CONFIG.:  PRR  BASELINE 


(b)  EFFECT  OF  ORBITER  INCIDENCE 
ANGLE  ON  ORBITER  NORMAL 
FORCE 


Sref  = 2690  FT2 
2 ref  = 1328  IN. 

MRP  = ORB.  NOSE  ON 
ET  CENTERLINE 

REF:  MSFCTWT  566  CONFIG:  MODIFIED  2A 
NOMINAL  SRB 

LONGITUDINAL 

POSITION 

100”  FORWARD  OF 
NOM.  POS. 


(c)  EFFECT  OF  SRB  LONGITUDINAL  (d.)  EFFECT  OF  SRB  LONGITUDINAL 
POSITION  ON  LAUNCH  VEHICLE  POSITION  LAUNCH  VEHICLE 

AXIAL  FORCE  PITCH  STABILITY 


Figure  2.  Typical  Results  of  Parametric  Configurational  Studies. 
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FOREBODY  DRAG 
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Figure  3.  Aerodynamic  Fairing  Concepts  for  Launch  Vehicle  Drag  Reduction. 
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(a)  SIGN  CONVENTION 


CD 

LU 


FREESTREAM  MACH  NUMBER  (Moo) 


(b)  ELEVON  DEFLECTION  SCHEDULE 


ELEVON 

DEFLECTION— DEG. 


FREESTREAM  MACH  NUMBER  (Moo)  FREESTREAM  MACH  NUMBER  (Moo) 

(c)  INBOARD  HINGE  (d)  OUTBOARD  HINGE 

MOMENT  COEFFICIENT  MOMENT  COEFFICIENT 


Figure  4.  Ascent  Elevon  Deflection  Schedule  Requirement. 
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• FOUR  BSMs  FORWARD  AND  FOUR  AFT 

• PERFORMANCE 

• WEB  ACTION  TIME  ~ 0.68  SECONDS 

• VACUUM  THRUST/MOTOR  ~ 21,000  POUNDS 

• AVERAGE  OPERATING  PRESSURE  = 1700  PSI 

Figure  5.  Booster  Separation  Motor  Orientation. 


(a)  BSM-Off 


(b)  BSM  On 


Figure  6.  Effect  of  BSM  on  Shuttle  Flowfield,  M^  = 4.5,  AEDC/VKF  Tunnel  A. 
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PRESSURE  DISTRIBUTIONS  (AIRLOADS) 


Figure  7.  Launch  Vehicle  Aerodynamic  Data  Base. 
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Figure  8.  Aerodynamic  Coefficient  Formulation. 


NOTES: 


• AX,AY,AZ  ARE 
ORTHOGONAL 
DISPLACEMENTS  OF  SRB 
NOSE  FROM  ITS  MATED 
POSITION 

• AX  MEASURED  POSITIVE 

AFT 

• AY  MEASURED  POSITIVE 

OUTBOARD  RIGHT 

• AZ  MEASURED  POSITIVE 

DOWN 

• Ac*  = (aSRB  — aOT) 

• A0=M0SRB-0OT) 

• SEPARATION  MOTOR 
JET-TO-FREESTREAM 
MOMENTUM  RATIO  IS  ALSO 
INDEPENDENT  VARIABLE 


Figure  9.  SRB  Separation  Aerodynamic  Independent  Variables 


AX  = 1100  INCHES  (FULL  SCALE) 
•HYPERCUBE  DATA  POINTS 
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STING 
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.NOSE 
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WITH  3a  DISPERSIONS 
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250  500  750  OUT 
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Figure  10.  Trajectory  Envelope  Cross  Section. 
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Figure  12.  Single  Sting/Single  Balance  Mounting  Arrangement. 


RELATIVE 

MOVEMENT 


Figure  13.  Model  Support  System  for  Early  Element  Tests. 
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PROXIMITY 
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AERO  DATA 
MEASURED 


ORB  + ET  + 
LSRB  + RSRB 


ET  + LSRB  + 
RSRB 


LSRB/RSRB 


Figure  14.  Single  Sting/Multiple  Balance  "Shell  Model"  Concept. 
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Figure  15.  Single  Sting /Multiple  Balance  Shell  Model  in  AEDC  16T  Tunnel 


Figure  16.  Dual  Sting/Single  Balance  Shell  Model  in  AEDC  16T  Tunnel. 
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BASE  PRESSURE  RATIO.  PB/Poo  PRESSURE  COEFFICIENT,  CP 


0 

t 


CHAMBER  PRESSURE.  Pc^ 


Figure  17.  Base  Flow-Exhaust  Plume  Phenomena. 


Figure  18.  Example  of  a Successful  Simulation  Parameter;  Cone-Cylinder  Geometry. 
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Figure  19.  Application  of  Plume  Simulation  Parameters  to  Wind  Tunnel  Testing. 


Figure  20.  Launch  Vehicle  Plume  Test  Model  in  ARC  UPWT. 
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Figure  22.  Transverse  Firing  Jet  Similarity  Parameter. 
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(a)  BSM  Plume-On. 


(b)  BSM  Plume-Off . 

Figure  23.  SRB  Separation  Test  Model  Installation  in  AEDC/VKF  Tunnel  A. 
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ABSTRACT 

The  Space  Shuttle  aerodynamics  and  performance  communities  were  challenged  to  verify  the 
Space  Shuttle  vehicle  (SSV)  aerodynamics  and  system  performance  by  flight  measurements. 
Historically,  launch  vehicle  flight  test  programs  which  faced  these  same  challenges  were  unmanned 
instrumented  flights  of  simple  aerodynamical ly  shaped  vehicles.  However,  the  manned  SSV  flight 
test  program  made  these  challenges  more  complex  because  of  the  unique  aerodynamic  configuration 
powered  by  the  first  man-rated  solid  rocket  boosters  (SRB).  The  analyses  of  flight  data  did  not 
verify  the  aerodynamics  or  performance  preflight  predictions  of  the  first  flight  of  the  Space 
Transportation  System  (STS-1).  However,  these  analyses  have  defined  the  SSV  aerodynamics  and 
verified  system  performance.  The  aerodynamics  community  has  also  been  challenged  to  understand 
the  discrepancy  between  the  wind  tunnel  and  flight  defined  aerodynamics.  This  paper  presents  the 
preflight  analysis  challenges,  the  aerodynamic  extraction  challenges,  and  the  postflight  analyses 
challenges  which  led  to  the  SSV  system  performance  verification  and  which  will  lead  to  the 
verification  of  the  operational  ascent  aerodynamcis  data  base. 


INTRODUCTION 


The  challenge  of  the  Space  Shuttle  program  was  to  develop  a reusable  spacecraft  which  would 
experience  a conventional  launch  through  a high  dynamic  pressure  environment,  perform  an  on-orbit 
mission  and  return  to  a conventional  aircraft  type  landing.  These  requirements  were  satisfied  by 
a complex  configuration  comprised  of  the  first  winged  orbital  spacecraft  (Orbiter),  first  man- 
rated SRB,  and  external  fuel  tank  (ET)  (figure  1).  During  the  development  of  this  vehicle,  the 
aerodynamics  and  performance  communities  were  challenged  to  assure  flight  safety  by  analysis  and 
to  verify  the  SSV  aerodynamics  and  system  performance  by  flight  test.  Historically,  flight  test 
programs  of  launch  vehicles  have  been  unmanned  instrumented  flights.  However,  the  Space  Shuttle 
program  management  decided  to  perform  an  orbital  manned  mission  on  the  first  mission  of  the  flight 
program.  This  decision  was  based  on  program  mission  requirements,  compressed  development 
schedules,  and  impact  of  vehicle  loss. 


PREFLIGHT  ANALYSIS  CHALLENGE 

The  manned  SSV  flight  test  program  challenged  the  ascent  communities  to  insure  flight  safety. 
Extensive  preflight  analyses  were  performed  to  identify  the  SSV  system  performance  and  structural 
sensitivities  to  potential  inflight  dispersions.  Once  these  sensitivities  were  identified  ascent 
trajectory  profiles  were  designed  which  satisfied  the  STS  mission  requirements  and  maintained 
adequate  margins  of  safety.  Initial  ascent  trajectory  design  concepts  for  the  SSV  employed  a 
gravity  turn  technique  to  maximize  vehicle  performance.  This  concept  maintained  a zero  angle-of- 
attack  (a  * 0)  throughout  the  first  stage  of  flight.  While  this  design  approach  was  found  to  be 
adequate  for  earlier  generation  launch  vehicles,  the  resulting  structural  load  environment  for  the 
SSV  was  unacceptable.  Therefore,  the  primary  challenge  for  the  ascent  community  was  to  identify 
the  ascent  flight  constraints  within  which  the  SSV  trajectory  profile  could  be  designed  to  provide 
adequate  margins  for  the  vehicle  structure  while  minimizing  the  impact  to  the  STS  performance 
capability  (illustrated  in  figure  2 and  3).  With  the  cooperation  of  the  structural,  aerodynamic 

and  trajectory  design  communities,  an  approach  using  structural  load  indicators  was  developed 
which  modeled  each  of  the  critical  SSV  structural  areas  (see  figures  4 and  5)  in  terms  of  the 
external  forces  on  the  element:  thrust;  aerodynamics;  and  inertia.  These  structural  load 

indicator  models  were  evaluated  for  various  flight  conditions  to  derive  the  flight  constraint 
envelopes.  To  insure  adequate  structural  margins,  the  structural  load  indicator  models  were 
evaluated  using  a six  degree-of-freedom  ascent  trajectory  simulation  to  determine  sensitivities 
and  criticality  of  the  various  indicators  to  potential  inflight  dispersions.  Figure  6 illustrates 

the  constraint  envelope  and  inflight  dispersions  evaluated  in  terms  of  flight  conditions.  Figure 
7 presents  the  measured  wind  dispersions  used  in  figure  6 to  provide  protection  for  inflight  winds 
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and  maintain  a high  launch  probability.  Figure  8 presents  the  resultant  flight  constraint 
boundaries  and  trajectory  design  dynamic  pressure  and  angle-of-attack  requirements.  These 
analyses  pointed  out  the  sensitivity  of  the  SSV  to  the  Orbiter  aerodynamics  which  resulted  in  the 
requirement  to  extract  the  Orbiter  aerodynamics  from  flight  measurements. 

By  the  mid  1970's,  to  provide  adequate  structural  margins  on  the  Orbiter  wing  and 

Orbiter/ET/SRB  (element)  attach  struts,  an  angle-of-attack  of  -2°  was  required  during  the 
transonic  regime  of  the  ascent  trajectory.  This  more  negative  a profile  was  achieved  at  the  cost 
of  approximately  700  pounds  of  payload  capability  relative  to  the  initial  trajectory  design.  In 
the  late  1970's,  the  aerodynamic  data  base  uncertainties  were  increased  from  a level  which 
considered  only  wind  tunnel  data  scatter  (tolerance)  to  a level  which  also  considered  model  scale 
to  full  scale  aerodynamic  uncertainties  (variations).  This  increase  was  made  to  protect  the  SSV 
against  the  potential  modeling  and  scale  effect  uncertainties  associated  with  the  complex  SSV 
configuration.  This  change  in  the  potential  inflight  dispersions  resulted  in  an  ascent  trajectory 

profile  design  with  a * -3°  and  a further  loss  of  payload  capability  of  approximately  800  pounds 

relative  to  the  a = -2°  design.  Thus,  the  trajectory  design  for  the  STS-1  had  protected  the  SSV 
against  aerodynamic  uncertainties  and  inflight  dispersions  to  provide  adequate  performance, 
acceptable  structural  loads  and  to  insure  high  launch  probability. 


AERODYNAMICS  EXTRACTION  CHALLENGE 


Since  the  preflight  analyses  were  based  on  ground  test  defined  aerodynamics,  the  aerodynamics 
community  was  challenged  to  develop  techniques  to  extract  the  aerodynamic  characteristics  of  the 
SSV,  elements  and  components  from  flight  data.  An  extraction  procedure  was  developed  which 

2 

substituted  known  or  measured  quantities  into  the  equations  of  motion  and  solved  for  the 
aerodynamic  forces  and  moments.  The  SSV  was  instrumented  to  measure  the  required  quantities: 
linear  and  angular  accelerations,  angular  rates,  thrust  vector  of  each  Space  Shuttle  main  engine 
(SSME)  and  SRB  (i.e.,  magnitude  and  direction),  and  trajectory  parameters.  These  measurements 
could  not  be  used  directly  to  extract  the  aerodynamic  characteristics,  but  required  some 
adjustments.  Analysis  techniques  were  developed  to  account  for  vehicle  characteristics, 
instrumentation  location  and  instrumentation  system  biases.  The  SSME  thrust  vector  analysis 
combined  the  elasticity  of  the  Orbiter  thrust  structure  and  measurement  of  thrust  vector  control 
(TVC)  actuator  stroke  to  determine  the  direction  of  the  thrust  vector.  Similarly,  the  structural 
characteristics  of  the  SRB  were  combined  with  the  SRB  TVC  actuator  stroke  measurement  to  determine 
the  SRB  thrust  vector  direction. 

Since  the  center  of  gravity  (eg)  of  the  SSV  moves  during  flight,  techniques  were  required  to 
relate  the  accelerometer  measurements  to  the  eg  location.  Acceleration  measurements  were  taken  at 
several  locations  on  the  Orbiter  and  SRB.  The  acceleration  analysis  used  all  compatible 
measurement  in  a least-squares  procedure  to  define  the  SSV  eg  acceleration.  Since  the  Orbiter  is 
not  a rigid  body,  accelerometer  misalignment  studies  were  required  to  determine  the  effect  of  body 
bending  on  the  aerodynamic  extraction  results.  These  analyses  indicated  that  the  expected 
misalignments  would  not  effect  the  aerodynamic  extraction  results. 

Flight  measurement  of  the  SSV  trajectory  parameters  and  configuration  parameters  were 
required  to  relate  the  extracted  aerodynamics  to  the  ascent  aeordynamic  design  data  base.  An  air 
data  system  was  designed  into  the  tip  of  the  ET  to  provide  pressure  measurements  from  which  the 
angle-of-attack,  angle-of-sideslip,  dynamic  pressure  and  Mach  number  could  be  determined  (figure 
9).  An  extensive  wind  tunnel  calibration  program  was  conducted  to  provide  correlation  between 
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these  pressure  measurements  and  the  required  trajectory  parameters.  Also,  flight  measurement  of 
the  Orbiter  elevon  position  was  required.  Measurements  of  the  elevon  actuator  stroke  were  made 
and  converted  to  elevon  angular  position  data.  Also,  techniques  were  developed  to  extract  elevon 
hinge  moments  from  actuator  pressure  measurements  and  strain  gauge  measurements.  The  flight 
elevon  position  analysis  combined  the  position  measurement,  the  extracted  hinge  moments,  and  the 
aeroelastic  characteristics  of  the  elevon  support  structure  to  determine  the  aeroelastic  elevon 
position. 

Since  preflight  analysis  had  identified  structural  sensitivities  to  the  element  (Orbiter,  ET 
and  SRB)  aerodynamics,  extraction  procedures  were  developed  to  define  the  element  aerodynamics. 

The  element  extraction  procedure  required  the  same  measurements  as  previously  described.  However, 

to  isolate  one  element  from  the  SSV  the  measurement  of  the  interface  loads  were  required.  Each 
Orbiter  to  ET  strut  and  each  SRB  to  ET  strut  (figure  4 and  5)  (except  the  forward  ball  fitting) 
were  instrumented.  From  the  measurement  of  the  strut  loads,  each  body  axis  interface  force  could 
be  determined.  A precise  calibration  of  each  flight  test  strut  assembly  was  performed.  These 
calibrations  were  used  to  determine  the  flight  measured  strains.  As  with  other  measurements. 
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biases  were  required  to  be  removed.  Removal  of  the  airload  and  inertial  load  acting  on  each  strut 
was  required.  The  initial  weight  of  the  Orbiter  prior  to  SSME  ignition  was  used  to  determine  the 
Orbiter  strut  bias.  A pre- ignition  SRB  strut  bias  could  not  be  determined  since  a preload  was 
present  on  the  SRB  struts  on  the  pad  which  was  released  at  lift-off.  The  SRB  strut  bias  was 
determined  by  using  the  strut  calibration  zero  load  point  and  the  strut  measurement  at  SRB 
separation. 

Prior  to  the  first  flight  of  the  SSV  the  capability  to  extract  the  SSV,  element  and  component 
(elevon  hinge  moment)  aerodynamics  was  achieved  by  the  aerdoynamics  community.  Although  preflight 
analyses  had  indicated  that  the  wing  and  vertical  tail  (components)  were  critical  structure  at 
some  flight  conditions,  no  procedures  were  developed  to  extract  these  component  aerodynamics.  The 
available  strain  gauge  instrumentation  was  considered  a structures  community  responsibility. 
Furthermore,  the  limited  amount  of  pressure  instrumentation  was  considered  verification  data  and 
no  procedures  were  developed  to  model  these  data. 


POSTFLIGHT  ANALYSIS  CHALLENGES 


The  aerodynamics  and  performance  communities  were  further  challenged  by  the  anomalies  which 
occurred  during  STS-1.  The  first-stage  trajectory  was  steeper  than  expected  (lofted)  which 
resulted  in  a SRB  staging  altitude  approximately  10,000  feet  higher  than  predicted  (figure  10). 
Post  flight  extraction  of  the  aerodynamic  forces  and  moments  revealed  that  significant  differences 
existed  from  the  baseline  longitudinal  forebody  and  base  aerodynamics  of  the  SSV  and  elements 
(figures  11  and  12). 

These  results  challenged  the  aerodynamic  community  to  understand  these  results  and  provide 
models  of  the  flight  derived  aerodynamics.  The  performance  communities  were  challenged  to 
reconstruct  the  observed  trajectory  anomalies  and  verify  subsystem  models  for  trajectory  design 
and  performance  prediction. 

Initially,  the  aerodynamics  community  thought  that  the  extracted  aerodynamic  results  were 
incorrect  because  the  observed  discrepancies  were  larger  than  the  conservative  aerodynamic 
variations.  However,  preliminary  trajectory  reconstructions  supported  the  flight  derived 
aerodynamics,  and  extensive  review  of  the  extraction  procedure,  particularly  thrust  vectors, 
resulted  in  only  minor  modifications.  STS-2  and  -3  resulted  in  similar  extracted  aerodynamic 
characteristics.  As  the  flight  test  program  continued,  the  trajectory  reconstruction  analyses 
developed  confidence  in  the  trajectory  design.  STS-4  was  designed  to  provide  the  aerodynamics 
community  with  flight  data  at  a less  negative  angle-of-attack.  After  STS-4,  gradient  and 
intercept  analyses  of  the  derivatives  (8C/3a  and  8C/38)  indicated  that  the  wind  tunnel  data  base 
derivatives  and  absolute  levels  were  incorrect  as  shown  in  figures  13  and  14.  These  results  were 
modeled  into  the  present  SSV  and  element  aerodynamic  data  bases. 

As  these  models  were  being  developed,  the  aerodynamic  community  was  attempting  to  understand 
the  discrepancy  between  wind  tunnel  and  flight  aerodynamics.  Center-of-pressure  analyses 
indicated  that  a positive  normal  force  increment  was  acting  on  the  aft  region  of  the  SSV  and 
primarily  on  the  Orbiter.  Assessment  of  limited  pressure  instrumentation  on  the  Orbiter  fuselage, 
wing  and  base  indicated  that  a higher  than  predicted  base  pressure  environment  existed  during 
flight  which  had  fed  forward  of  the  Orbiter  base.  A review  of  the  plume  simulation  used  for  SSV 
wind  tunnel  tests  was  conducted.  Studies  using  an  analytical  program  and  flight  test  base 
pressures  concluded  that  the  plume  simulation  parameter  (used  to  set  test  conditions)  was 

4 

deficient  and  required  a temperature  function  to  account  for  hot  gas  effects.  A post  flight  wind 
tunnel  test  was  conducted  to  simulate  the  flight  base  pressure  environment.  Preliminary  results 
seem  to  verify  flight  pressure  measurements  in  the  elevon  region  of  the  wing  and  aft  fuselage 
(figure  15  and  16).  Analyses  of  the  post  flight  wind  tunnel  test  are  continuing  and  will 
determine  what  part  of  the  observed  difference  was  due  to  plume  simulation  deficiencies.  The 
remaining  difference  is  assumed  to  be  Reynold's  number  effects.  Since  post  flight  wind  tunnel 
data  analyses  will  not  be  complete  for  some  time  and  since  only  limited  flight  pressure  data  was 
obtained,  problems  in  modeling  the  flight  force  and  moment  increments  into  the  external  pressure 
distributions  have  prevented  complete  verification  of  the  ascent  aerodynamic  data  bases. 

Since  the  SSV  pressure  distributions  are  questionable,  the  day-of-launch  assessment  of  wing 
loads  is  questionable.  Wing  pressure  distributions  are  inputs  to  the  current  load  indicator 
equations.  Techniques  were  developed  to  determine  the  wing  load  distribution  from  flight  strain 
gauge  data.  Attempts  to  modify  the  wind  tunnel  derived  pressure  distributions  based  on  flight 
pressure  measurements  have  failed  to  match  loads  data  extracted  from  wing  strain  gauge  data. 
However,  the  gauge  data  was  questioned  and  a check  calibration  performed  after  STS-5  revealed  that 
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several  key  gauges  either  had  the  wrong  scaling  factors  or  reversed  polarity.  After  using  the 
check  calibration  data,  the  extracted  wing  loads  comparisons  did  not  improve.  Currently,  the 
aerodynamics  and  structures  communities  are  implementing  plans  to  correlate  calculated  internal 
stresses  using  revised  pressure  distributions  with  measured  flight  stresses.  The  results  of  this 
effort  will  be  verified  SSV  pressure  distributions. 

The  performance  communities'  trajectory  reconstruction  work  provided  the  basis  for 
verification  of  the  SSV  system  performance.  The  trajectory  reconstruction  of  STS-4  using  flight 
derived  aerodynamics  and  post  flight  subsystem  model  updates  (SSME  Isp  and  thrust;  SRB  Isp  and 
thrust;  and  gimbals)  matched  the  vehicle  tracking  data  (BET),  air  data  system  parameters, 
occurrence  of  flight  events,  ET  propellants  remaining  at  MECO  (table  1)  and  attach  structure 
loads.  Figures  17,  18,  and  19  present  the  trajectory  parameter  reconstruction  comparisons.  These 
reconstructions  also  provide  load  comparisons  of  previously  critical  structural  loads  (figure  20). 
The  trajectory  reconstruction  task  also  produced  a reassessment  of  trajectory  design  constraints. 
In  terms  of  payload  capability,  the  flight  base  aerodynamics  increased  the  SSV  performance 
approximately  1000  pounds.  However,  the  current  evaluation  of  wing  loads  reflected  a need  to  bias 

the  ascent  trajectory  profile  to  a = -5°  to  maintain  acceptable  margins.  This  angle-of-attack 
requirement  during  the  first  stage  cost  approximately  1100  pounds  of  payload  capability  relative 

to  the  a = -3°  used  during  the  flight  test  program.  Figure  21  summarizes  the  impact  of 
maintaining  structural  margin  requirements  as  a result  of  changes  to  the  aerodynamic  data  base  on 
the  ascent  trajectory  design  and  SSV  performance  from  the  early  design  phase  of  the  SSV  to  the 
current  operational  baseline.  Therefore,  verification  of  SSV  performance  was  achieved  by 
trajectory  and  load  reconstructions  that  modeled  subsystem  changes  and  accounted  for  as  flown  wind 
profiles . 


CONCLUSION 


The  Space  Shuttle  aerodynamcis  and  performance  communities  have  met  the  challenges  of  the 
Space  Shuttle  Program.  From  a trajectory  design  and  performance  point  of  view,  the  SSV 
aerodynamic  characteristics  and  paylaod  capabilities  have  been  defined,  modeled  and  verified.  In 
addition  the  element  aerodynamic  characteristics  have  been  defined  and  verified,  which  prior  to 
STS-1  were  considered  most  significant  to  the  SSV  structure  and  to  trajectory  design.  However, 
the  flight  results  changed  the  emphasis  from  the  element  aerodynamics  to  the  external  pressure 
distribution  of  the  Orbiter  wing.  Because  of  limited  external  flight  pressure  instrumentation, 
flight  strain  gauge  data  must  be  used  to  extract  the  external  pressure  distributions.  Attempts 
to  model  the  strain  gauge  results  failed  to  predict  measured  stresses  when  pre-STS-1  wing  load 
indicator  equations  were  used.  The  aerodynamics  community  initiated  regression  analyses  of  flight 
wing  strain  measurements  to  produce  wing  load  indicators  that  would  provide  an  adequate  tool  for 
day-of-launch  wing  load  calculations  to  insure  flight  safety.  Once  this  method  was  shown  to 
provide  excellent  prediction  capability,  the  structure  community  implemented  the  procedure  for 
critical  wing  structure.  Also,  the  aerodynamics  community  initiated  a cooperative  effort  of  theT 
aerodynamics  and  structures  communities  to  define  the  SSV  pressure  distribution  through  an 
iterative  procedure  of  pressure  distribution  definition,  internal  loads  calculations,  and  flight 
comparisons.  The  initial  step  in  this  effort  has  pointed  out  that  the  current  pressure 
distributions  are  not  adequate.  Review  of  the  effort  to  date,  points  out  the  need  for  the 
structures  community  to  insure  that  the  effects  of  fuselage  torison  and  bending  on  strain  gauge 
measurements  are  defined,  understood  and  modeled.  Therefore,  the  above  cooperative  effort  will 
provide  definition  and  verification  of  the  ascent  aerodynamics  pressure  distributions  which  will 
complete  the  ascent  aerodynamics  operational  data  base. 

Finally,  the  efforts  of  the  aerodynamics  and  performance  communities  to  meet  the  Space 
Shuttle  challenges  have  provided  the  Shuttle  Program  management  insight  to  trajectory  design 
constraints,  performance  improvements  and  limitations,  effects  of  flight  defined  aerodynamics,  and 
day-of-launch  risk  assessments. 
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Fig.  1 Space  Shuttle  Launch  Vehicle  Configuration. 
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Fig.  3 Wing  Load  and  Performance  Trade 
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Fig.  2 Wing  Load  and  Performance  Trade  Study 
with  Dynamic  Pressure. 


Fig.  5 Attach  Strut  Load  Indicators 
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Fig.  6 Flight  Constraint  Envelope. 
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Fig.  7 SSV  Response  to  Wind  Profiles  in  the 
Pitch  and  Yaw  Planes. 


Fig.  8 Flight  Constraint  Boundary. 


Fig.  9 Ascent  Air  Data  System  Configuration. 
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Fig.  10  STS- 1 Trajectory  Anomaly 
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Fig.  11  Comparison  of  STS-1  Flight  Base  Axial  Force  and  Design  Data  Base  Axial  Force. 
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Fig.  12  STS-1  Normal  Force  and  Pitching  Moment  Comparisons. 
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Fig.  13  Gradient  Analysis  of  Flight  Pitching  Moment. 
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Fig.  14  Gradient  Analysis  of  Flight  Normal  Force. 
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Fig.  15  Wing  Pressure  Distribution  Comparison. 


Fig.  16  AFT  Fuselage  Pressure  Distribution 
Comparison. 
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Fig.  17  STS-4  Dynamic  Pressure  Reconstruction. 
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Fig.  18  STS-4  Angle-of -Attack  Reconstruction, 
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Fig.  19  STS-4  Angle-of-side  Reconstruction. 


STS-4  ASCENTTRAJECTORY  RECONSTRUCTION 


Fig.  20  STS-4  Attach  Load  Reconstruction. 
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Table  1.  Summary  of  STS-4  Trajectory  Reconstruction. 


STS-4  RECONSTRUCTION  SUMMARY 
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ABSTRACT 


Recovery  and  reuse  of  the  Space  Shuttle  solid  rocket  boosters  was  baselined  at  the  initiation  of 
the  program  to  support  the  primary  goal  to  develop  a low  cost  space  transportation  system.  The  recovery 
system  required  for  the  170,000-lb  boosters  was  for  the  largest  and  heaviest  object  yet  to  be  retrieved 
from  exoatmospheric  conditions.  State-of-the-art  design  procedures  were  ground-ruled  and  development 
testing  minimized  to  produce  both  a reliable  and  cost  effective  system. 

The  ability  to  utilize  the  inherent  drag  of  the  boosters  during  the  initial  phase  of  reentry  was  a 
key  factor  in  minimizing  the  parachute  loads,  size  and  weight.  A wind  tunnel  test  program  was  devised 
to  enable  the  accurate  prediction  of  booster  aerodynamic  characteristics.  Concurrently,  wind  tunnel, 
rocket  sled  and  air  drop  tests  were  performed  to  develop  and  verify  the  performance  of  the  parachute 
decelerator  subsystem.  Aerodynamic  problems  encountered  during  the  overall  recovery  system  development 
and  the  respective  solutions  are  emphasized. 


INTRODUCTION 

At  the  onset  of  the  Space  Shuttle  program,  numerous  trade  studies  investigated  means  to  develop  a 
cost  effective  space  transportation  system.  One  conclusion  drawn  from  these  studies  was  that  recovery, 
refurbishment  and  reuse  of  the  Solid  Rocket  Boosters  (SRBs)  would  provide  a significant  cost  savings 
over  expendable  boosters. * This  conclusion  was  based  in  part  on  the  assumption  that  a recovery  system 
could  be  developed  utilizing  a current  state-of-the-art  design  approach.  This  challenge  was  accepted  by 
the  Marshall  Space  Flight  Center  in  May  1972  when  this  center  was  given  overall  responsibility  for 
developing  the  SRB  recovery  system.  The  challenge  has  been  successfully  met  as  evidenced  by  the  initial 
Shuttle  flight  verification  test  in  April  1981  and  in  subsequent  Shuttle  flights. 

Aerodynamics  have  played  a key  roll  in  the  recovery  system  development.  The  purpose  of  this  paper 
is  to  address  some  of  the  aerodynamic  issues  and  trades  and  how  various  aerodynamic  challenges  were  met 
through  a combined  conventional  and  innovative  systematic  approach  aimed  at  providing  both  a reliable 
and  cost  effective  system. 

A trace  of  the  historical  development  of  the  recovery  system  and  the  aerodynamic  challenges 
encountered  cannot  begin  without  first  a brief  description  of  the  SRB  configuration  and  reentry  profile. 
Refering  to  the  reentry  sequence  in  Figure  1,  the  twin  boosters  burn  out  and  separate  from  the  remaining 
Orbiter /External  Tank  at  an  altitude  of  approximately  150,000  ft.  After  reaching  an  apogee  near 
220,000  ft,  the  170,000-lb  spent  SRBs  reenter  the  atmosphere  in  a random  tumbling  mode.  After  an 
initial  deceleration  phase  during  which  the  Mach  number  decreases  from  approximately  5.0  to  0.5,  the 
nose  cap  is  ejected  initiating  the  deployment  sequence  of  the  decelerator  subsystem  parachutes.  The 
54-ft  drogue  parachute,  deployed  at  an  altitude  of  approximately  15,000  ft,  stabilizes  the  booster  in  a 
tail  first  attitude.  The  drogue  is  also  used  to  deploy  a cluster  of  three  115-ft  main  parachutes  at  an 
altitude  near  6500  ft.  The  main  parachute  system  provides  the  final  deceleration  to  the  nominal  87 
ft /sec  water  impact  velocity. 

A schematic  of  the  SRB  illustrating  the  location  of  the  recovery  system  major  elements  is  provided 
in  Figure  2.  The  parachutes  packs,  as  shown,  are  contained  in  the  forward  portion  of  the  booster.  An 
11.5-ft  pilot,  used  to  deploy  the  drogue,  is  located  in  the  nose  cap.  At  the  proper  altitude,  determined 
by  a barometric  switch,  the  nose  cap  is  jettisoned  by  firing  three  30,000-lb  thrusters.  As  shown  by 
the  sequence  in  Figure  3,  the  nose  cap  is  connected  by  a three-legged  bridle  and  riser  to  the  pilot  pack, 
and  utilizing  the  drag  of  the  cap  deploys  the  pilot  parachute. 

Main  parachute  deployment,  again  initiated  by  a baroswitch  signal,  occurs  when  the  frustum  is 
severed  by  a linear  shaped  charge.  The  frustum  then  descends  under  the  drogue  to  water  impact  and  is 
recovered  along  with  the  booster  approximately  140  n.mi.  downrange  of  the  launch  site. 
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ESTABLISHMENT  OF  RECOVERY  SYSTEM  BASELINE 


In  the  initial  design  definition  phase  of  SRB  recovery  system  development,  two  primary  issues 
received  the  major  emphasis.  These  were  (1)  how  to  provide  high  altitude  booster  deceleration  to 
achieve  conditions  suitable  for  parachute  deployment,  and  (2)  how  to  optimize  the  recovery  system  for 
water  impact.  For  both  of  these  issues,  the  requirements  to  utilize  only  state-of-the-art  concepts  and 
to  minimize  cost  and  complexity  of  recovery  eliminated  some  of  the  potential  options  such  as  the  use  of 
active  stabilization  or  attitude  control  systems. 

Some  of  the  options  considered  for  the  high  altitude  deceleration  phase  of  reentry  are  shown  in 
Figure  4.  These  include  the  use  of  various  drag  producers  such  as  extendable  flaps,  drag  petals  and 
inflatable  type  devices  such  as  ballutes.  However,  a drawback  to  each  of  these  methods  is  that  they  all 
tend  to  orient  the  booster  centerline  in  the  streamwise  direction  resulting  in  a tremendous  decrease  in 
SRB  drag.  From  this  standpoint,  a high  angle  of  attack  or  "broadside"  reentry  mode  appeared  highly 
desirable.  In  fact,  the  natural  aerodynamic  drag  of  the  booster  alone  could  potentially  provide  the 
deceleration  required  to  generate  the  conditions  needed  at  parachute  deployment.  Although  the  best 
method  of  achieving  a near  broadside  reentry  mode  had  not  been  determined,  this  reentry  concept  was 
adopted  because  of  the  numerous  advantages  it  offered. 

Concurrently,  other  studies  were  being  performed  to  optimize  the  final  deceleration  system.  One 
key  trade  considered  an  all  parachute  versus  a hybrid  parachute  braking  rocket  system.  The  results 
(Fig.  5)  indicated  that  for  water  impact  velocities  above  65  ft/sec  a pure  parachute  system  would  be 
lighter.  Studies  of  water  impact  had  concluded  that  a 80  to  100  ft/sec  tail  first  impact  would  provide 
a good  compromise  between  initial  impact  and  slap  down  loads.  The  pure  parachute  system  was  therefore 
baselined  to  provide  both  a lighter  weight  and  less  complex  system. 

With  a booster  recovery  scheme  developed,  several  key  aerodynamic  challenges  remained  including 
(1)  determining  the  best  means  of  achieving  a broadside  reentry,  (2)  developing  an  SRB  aerodynamic  data 
base,  (3)  establishing  design  requirement  for  the  parachute  system,  (4)  optimizing  the  parachute  system 
from  a design/perf ormance  standpoint,  and  (5)  verifying  overall  performance  through  a systematic  and 
cost  effective  development  test  program. 

Since  the  parachute  design  requirements  were  directly  dependent  on  the  SRB  initial  deceleration 
phase,  it  was  paramount  that  the  initial  SRB  deceleration  phase  be  investigated  first.  If  the  booster 
center  of  gravity  were  ideally  located  at  approximately  53  percent  body  length  from  the  SRB  nose  (near 
centroid  of  area)  the  booster  would  tend  to  trim  at  an  angle  of  attack  near  the  optimum  90-deg.  The 
booster  center  of  gravity  at  burnout,  however,  is  5 or  6 percent  further  aft  which  causes  the  booster 
to  tend  to  trim  in  a somewhat  tail  first  and  lower  drag  attitude. 

Early  studies  considered  an  aerodynamic  "fix"  to  force  the  booster  to  reenter  closer  to  90  deg. 

To  accomplish  this  several  possibilities  were  explored.  In  one  concept  strakes  were  added  to  the  fore 
and  aft  section  of  the  SRB  on  opposite  sides  of  the  vehicle.  The  strakes  would  create  a yawing  moment 
sufficient  to  induce  a flat  spin.  This  concept,  however,  required  a tight  control  of  the  static  margin 
and  also  roll  stabilization  to  assure  that  the  strakes  would  be  oriented  for  maximum  effectiveness. 

A more  practical  solution  proposed2  also  utilized  strakes  but  in  a somewhat  different  manner.  By 
adding  strakes  at  several  circumferential  locations  on  the  SRB  aft  skirt,  an  effective  rearward  shift 
in  center  of  pressure  of  approximately  one  percent  body  length  could  be  achieved. 

Since  the  addition  of  strakes  added  weight  and  cost  to  the  SRB,  recovery  studies  continued  to 
investigate  reentry  with  an  unmodified  booster.  The  major  concern  with  this  approach  dealt  with  the 
predictability  of  conditions  at  parachute  deployment.  Because  of  an  integral  effect  of  the  phasing  of 
the  lift  vector  during  reentry,  significantly  different  trajectories  could  result  from  small  differences 
in  booster  mass  characteristics,  aerodynamics,  and  other  system  uncertainties.  It  was  difficult  not 
only  to  establish  a nominal  reentry  trajectory  but  also  to  define  reasonable  worst  case  conditions  to 
establish  design  requirements  for  nose  cap  separation  and  drogue  deployment. 

The  solution  was  to  utilize  a "Monte  Carlo"  approach  to  establish  a set  of  approximately  400 
possible  trajectories.  In  each  trajectory  the  system  dispersions  were  selected  using  a random  distri- 
bution for  each  established  uncertainty.  The  booster  aerodynamics,  except  for  the  center  of  pressure, 
were  also  treated  in  this  manner.  The  center  of  pressure  dispersion  was  fixed  at  the  95-percentile 
worse  case  direction  (forward)  to  establish  a set  of  design  conditions  for  parachute  deployment. 

One  result  of  the  reentry  analysis  was  the  establishment  of  a booster  center  of  gravity  aft  limit 
for  recovery  system  design  purposes.  As  the  center  of  gravity  moves  aft,  the  conditions  at  drogue 
deployment  become  increasingly  sensitive  to  system  uncertainties  and  the  chances  of  a "lock-up"  to  a 
catastrophic  tail  first  trim  more  probable.  The  final  selection  of  a 59-percent  aft  limit  was  a 
reasonable  compromise  between  SRB  weight  distribution  and  acceptable  conditions  for  drogue  deployment. 
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Using  the  Monte  Carlo  trajectory  set,  parachute  design  requirements  could  also  be  traded  against 
probability  of  a successful  recovery  to  optimize  the  recovery  system  from  a cost  standpoint.  This 
resulted  in  a design  based  on  a 99th  percentile  trajectory  eliminating  the  few  cases  resulting  in  near 
tail  first  reentries. 

The  primary  tasks  remaining  were  to  (1)  develop  a valid  aerodynamic  data  base  for  the  final  SRB 
baseline  configuration,  and  (2)  develop  an  optimum  parachute  system  to  meet  the  established  requirements. 
The  manner  in  which  these  tasks  were  undertaken  will  now  be  addressed. 


SRB  AERODYNAMIC  DATA  BASE  DEVELOPMENT 


The  SRB  reentry  aerodynamic  characteristics  were  developed  primarily  by  a series  of  wind  tunnel 
tests  utilizing  various  size  models,  several  test  facilities  and,  in  some  instances,  specialized  test 
techniques.  The  data  base  development  task  was  made  more  complex  by  the  large  test  matrix  required  to 
encompass  the  wide  range  of  potential  reentry  conditions  inherent  to  a randomly  tumbling  reentry  body. 
Other  problems  experienced  were  attributed  to  Reynolds  number  and  sting  interference  effects. 

REYNOLDS  NUMBER  EFFECTS 

Although  a major  portion  of  the  SRB  reentry  is  supersonic,  the  greatest  challenge  in  developing 
the  data  base  was  to  obtain  accurate  aerodynamic  characteristics  in  the  subsonic  flow  regime.  The 
reentering  SRB  is  essentially  a cylinder  in  crossflow  type  problem  that  is  compounded  by  the  existence 
of  very  large  Reynolds  numbers  2 x 10 0 and  SRB  protuberance  effects.  Because  of  the  importance  of 
Reynolds  number,  every  attempt  to  match,  maximize  or  determine  the  effects  of  this  parameter  on  SRB 
reentry  aerodynamics  was  incorporated  into  each  test. 

Figure  6 provides  a comparison  between  flight  Reynolds  number  and  levels  obtained  in  wind  tunnel 
testing.  As  shown,  a reasonably  close  match  was  achieved  with  tests  in  the  MSFC  High  Reynolds  Number 
Wind  Tunnel  (HRWT) . Reynolds  numbers  up  to  2.0  x 10$  were  also  obtained  in  large  (2.8  percent)  model 
tests  in  the  Ames  Unitary  Tunnel.  As  expected  large  variations  with  Reynolds  number  were  obtained. 

STING  INTERFERENCE  EFFECTS 

Although  sting  interference  effects  are  present  in  practically  all  wind  tunnel  test  results,  the 
magnitude  of  the  error  introduced  can  normally  be  ignored.  For  the  SRB  tests,  however,  sizable  sting 
effects  were  sometimes  obvious  as  illustrated  in  Figure  7.  The  pitching  moment  coefficients  presented 
as  a function  of  angle  of  attack  were  obtained  for  identical  configurations  and  conditions  using  two 
different  model  support  systems;  one  a side  mounted  strut  and  the  other  a sting  attached  to  the  nose  of 
the  SRB  model.  The  discontinuity  is  indicative  of  the  presence  of  sting  effects  but  not  necessarily 
the  magnitude  since  both  sets  are  erroneous  to  some  degree. 

Sting  interference  problems  have  typically  been  associated  with  the  testing  of  bodies  at  high 
angles  of  attack.  However,  in  the  SRB  tests  the  problem  has  been  amplified  by  the  necessity  to  test  at 
high  Reynolds  numbers  where  the  resulting  high  loads  dictate  the  use  of  massive  model  support  hardware. 
However,  even  the  low  Reynolds  number  tests  utilizing  smaller  struts  demonstrated  significant  sting 
effects  and  made  comparing  data  obtained  from  different  facilities  at  similar  conditions  extremely 
difficult.  The  severity  of  the  problem  is  also  illustrated  by  Figure  7 which  shows  that  the  sting 

effect  can  have  a sizeable  influence  on  the  apparent  static  trim  angle.  The  20-deg  difference  measured 

by  the  two  systems  would  not  be  acceptable  if  treated  as  an  uncertainty  in  developing  conditions  at  nose 
cap  deployment. 

Because  of  the  criticality  of  defining  the  proper  reentry  conditions,  a special  test  program3  was 
initiated  to  quantitatively  determine  the  effects  of  sting  interference.  The  goal  of  this  program  was 
to  (1)  obtain  sting  interference  corrections  for  model  support  systems  used  in  MSFC  TWT,  MSFC  HRWT  and 
Ames  Research  Center  test  results,  and  (2)  determine  the  optimum  sting  arrangement  to  minimize  sting 
effects  in  future  tests. 

The  technique  employed  was  similar  to  that  utilized  in  Reference  4.  That  is,  a dummy  sting  was 
used  in  conjunction  with  a live  balance  and  sting  to  back  out  the  sting  effect  (Fig.  8).  Hardware  was 

also  developed  to  determine  corrections  for  both  the  nose  and  side  mount  configurations.  This  provided 

an  indication  of  the  resulting  data  uncertainty,  due  partially  to  a mutual  interference  effect  between 
dummy  and  live  sting,  and  also  the  data  needed  to  establish  the  best  sting  setup  for  given  conditions. 

A photograph  of  the  sting  interference  test  setup  for  the  HRWT  facility  (Fig.  9)  illustrates  the 
size  of  the  sting  system  relative  to  the  SRB  model.  An  example  comparison  of  the  sting  corrected  nose 
and  side  mount  data  with  design  data  and  large  model  test  results  (SA11F)  is  shown  in  Figure  10.  In 
this  particular  case,  the  corrected  data  are  to  the  right  of  both  data  sets.  The  resulting  higher  trim 
angle  creates  a more  severe  reentry  environment,  further  illustrating  the  importance  of  these  tests. 
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PARACHUTE  PERFORMANCE  DATA  BASE  DEVELOPMENT 


The  parachute  system  for  the  SRBs  evolved  from  a systematic  development /verification  test  program 
that  included  wind  tunnel,  rocket  sled  and  air  drop  testing.  In  order  to  minimize  development  costs  it 
was  mandatory  that  the  number  of  air  drop  tests  be  reduced  from  the  thirteen  originally  planned  to  only 
six.  This  success  oriented  approach  placed  a greater  burden  on  predrop  configuration  design  optimiza- 
tion including  that  of  the  parachute  deployment  method  and  parachute  configuration  to  achieve  the  desired 
performance. 


WIND  TUNNEL  TEST  PROGRAM 

Wind  tunnel  tests'^*  were  performed  for  two  primary  purposes.  One  was  to  parametrically  inves- 
tigate the  performance  of  20-deg  conical  ribbon  parachutes  to  augment  the  data  base  available.  The 
configurations  tested  were  appropriate  for  the  drogue,  drogue  pilot  and  main  parachute  system.  The 
second  major  objective  was  to  investigate  several  potential  deployment  methods  for  the  drogue  parachute 
(Fig.  11).  One-eighth  scale  models  of  the  drogue  parachute  of  16-  and  24-percent  porosity  were  used 
for  the  drogue  performance  and  drogue  deployment  phases  of  the  test.  Since  the  same  parachute  models 
were  also  used  for  the  main  parachute  performance  tests  the  ribbon  width  and  spacing  was  geometrically 
scaled  for  the  drogue  parachutes  only. 

A photograph  of  the  model  used  in  the  drogue  deployment  tests  is  shown  in  Figure  12.  In  these 
tests  both  the  parachutes  packs  and  the  nose  cap  were  geometrically  and  mass  scaled  to  simulate  the 
deployment  dynamics.  A photograph  showing  typical  parachute  models  is  shown  in  Figure  13. 

These  tests  accomplished  all  of  the  goals  established.  A recommended  method  of  deploying  the 
drogue  parachute  was  later  adopted  and  proved  successful.  Performance  characteristics  were  established 
for  the  SRB  candidate  20-deg  conical  ribbon  parachutes  including  the  effects  of  geometric  porosity, 
reefing,  clustering,  suspension  line  length  and  forebody  interference.  These  data  enabled  a sound 
configuration  selection  in  the  early  design  stage  that  would  basically  remain  unchanged  throughout  the 
remaining  development  program. 


ROCKET  SLED  TEST 

The  initial  phase  of  parachute  deployment,  i.e.,  nose  cap  separation  and  pilot  parachute  deployment, 
was  considered  a critical  aspect  of  the  recovery  scheme.  To  verify  that  the  full  scale  flight  configu- 
ration would  perform  as  predicted  and  demonstrated  in  scaled  model  tests,  a rocket  sled  test  was  per- 
formed®*^ at  the  Rocket  Sled  Test  Facility  at  Sandia  Laboratories,  Albuquerque,  New  Mexico.  This  test 
provided  a functional  checkout  of  nose  cap  separation,  structural  verification  of  the  nose  cap/pilot 
chute  rigging  under  design  limit  load  environment  and  aerodynamical ly  the  dynamic  behavior  of  nose  cap 
separation  and  pilot  deployment  for  both  a worst  case  windward  (a  = 80°)  and  a high  alpha/high  dynamic 
pressure  (140  deg/270  psf)  test  condition. 

The  sled  test  was  both  a technically  sound  and  cost  effective  alternative  to  an  air  drop  for 
development  testing  this  portion  of  the  recovery  system.  Primarily,  it  provided  a means  of  controlling 
the  most  critical  test  parameters  such  as  velocity  and  SRB  angle  of  attack.  Figure  14  illustrates  the 
general  configuration  and  the  test  setup  for  the  80-deg  angle-of-attack  test.  The  configuration  was 
comprised  of  a flight-type  nose  cap,  jettisoned  by  firing  three  thrusters,  and  an  adapter  representing 
a small  portion  of  the  nose  cap  frustum. 

For  the  80-deg  test,  16  HVAR  (6500-lb  thrust)  rockets  were  used  to  accelerate  the  text  fixture 
down  the  5000-ft-long  track  to  a peak  velocity  of  465  ft/sec.  Following  a brief  coast  period,  the  nose 
cap  was  ejected  at  a dynamic  pressure  of  197  psf.  The  test  sequence  is  shown  in  Figure  15.  No  deploy- 
ment problems  were  experienced  and  the  cap  cleared  the  drogue  and  pilot  chute  packs  by  a substantial 
margin. 

Similar  success  was  achieved  with  the  140-deg  test  which  utilized  21  HVAR  rockets.  For  each  of 
the  tests,  film  analysis  and  laser  tracking  data  were  used  to  determine  nose  cap  ejection  velocities 
and  the  cap  displacement  relative  to  the  parachute  packs. 

AIR  DROP  TESTS 

An  important  element  of  the  SRB  decelerator  subsystem  development  program  was  the  air  drop 
program^* 11  performed  at  the  National  Parachute  Test  Range,  El  Centro,  California.  These  tests  were 
used  to  provide  functional,  structural  and  performance  evaluation  of  the  overall  parachute  system.  The 
program  consisted  of  six  drops  employing  a 48,000-lb  drop  test  vehicle  (DTV)  which  was  released  from 
the  B-52  mothership. 

A schematic  of  the  DTV  configuration  is  shown  in  Figure  16.  The  major  components  include  a ballast 
section,  a flare  section,  an  aft  facing  frustum  and  a nose  cap.  Three  fins,  not  shown  in  this  figure. 
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were  added  beginning  with  the  third  drop  test  to  improve  the  DTV  stability.  Similar  to  the  flight 
booster,  the  drogue  and  pilot  chute  packs  are  contained  in  the  nose  cap  and  the  main  parachute  pack  in 
the  frustum.  However,  unlike  the  flight  sequence  which  is  initiated  by  ejecting  the  nose  cap,  the  DTV 
contains  a small  mortar  deployed  vane  chute  which  deploys  a 11.5-ft  nose  cap  extraction  chute. 

A comparison  of  the  relative  size  of  the  DTV  and  SRB  is  shown  in  Figure  17.  The  significant  weight 
difference  (48,000  versus  170,000  lb)  rendered  it  impossible  to  develop  significant  loads  in  more  than 
one  reefing  stage  of  the  drogue  or  main  during  a single  test.  Furthermore,  in  some  cases,  test  peculiar 
reefing  ratios  and  sequencing  were  required  to  set  up  the  desired  deployment  condition.  For  the  main 
chute  cluster  tests,  the  DTV  deceleration  was  so  great  during  deployment  that  it  was  not  possible  to 
obtain  a high  load  condition.  Single  main  chute  tests  were  therefore  used  to  evaluate  the  parachute 
structural  integrity  and  cluster  tests  at  flight  deployment  conditions  used  to  assess  the  functional 
and  performance  aspects. 

A matrix  of  the  drop  test  program  and  the  primary  test  objectives  is  contained  in  Table  I.  Note 
that  in  some  tests  planned  objectives  were  not  fully  met.  The  reasons  involve  not  meeting  test  condi- 
tions (Test  1),  not  attaining  the  desired  loads  (Test  2),  or  in  having  a significant  failure  (Test  3). 

The  objectives  were  met,  however,  within  the  total  drop  test  program. 

A typical  drop  test  sequence  is  illustrated  in  Figure  18.  The  test  conditions  for  the  drogue 
initial  inflation  were  achieved  by  allowing  the  DTV  to  free-fall  for  a predetermined  time  from  the  drop 
altitude  ranging  from  approximately  16,000  to  22,000  ft. 

The  measurement  program  consists  of  drogue  and  main  chute  load  sensors,  acceleromters,  rate  gyros, 
extensometers  and  a total  pressure  probe.  Photographic  coverage  included  two  DTV  onboard  cameras,  chase 
plane  cameras,  and  ground  based  cameras.  Space  position  data  were  obtained  from  the  range  cinetheodolite 
system. 

12 

A typical  performance  comparison  between  wind  tunnel  and  drop  test  results  is  contained  in  Figure 
19.  In  general,  the  drop  tests  verified  the  predrop  test  performance  predictions  for  the  full  open 
parachutes.  The  drop  tests  also  permitted  a refinement  of  the  reefing  line  lengths  to  balance  or 
optimize  the  loads  experienced  on  each  of  the  three  stages  for  both  drogue  and  main  parachute  systems. 

Aside  from  the  measured  data  obtained,  visual  coverage  of  the  drop  test  program  provided  a sig- 
nificant insite  into  the  aerodynamic  behavior  of  the  pilot,  drogue  and  main  parachute  system  during 
both  the  deployment  process  and  during  steady  state  conditions.  Figure  20  illustrates  some  of  the 
drogue  deployment  characteristics  that  were  revealed  during  Test  2.  As  the  drogue  canopy  emerged  from 
the  bag,  the  sailing  lines  rotated  the  canopy  approximately  180  deg  relative  to  the  DTV.  This  also 
caused  a twisting  or  wrap-up  of  the  drogue  suspension  lines  as  shown.  Although  undesirable,  no  damage 
or  appreciable  drag  loss  resulted  from  this  behavior.  This  anomaly  was  traced  to  the  use  of  a test 
peculiar  reefed  pilot  parachute  which  did  not  provide  sufficient  drogue  pack  acceleration  to  overcome 
aerodynamic  forces  on  the  lines. 

Main  parachute  deployment  has  always  been  a major  concern  because  the  parachutes  must  be  deployed 
out  of  a hard  container  (frustum)  containing  jagged  edges  at  the  separation  plane.  In  Test  5 the 
frustum  moved  laterally  after  separating  causing  a skewed  deployment  of  the  three  main  parachutes.  The 
cause  of  this  is  thought  to  be  related  to  the  dynamic  motion  of  the  DTV  prior  to  frustum  separation. 
Another  problem  experienced  in  single  main  tests  is  that  of  inflation  overtake.  To  meet  the  Test  2 
objective  of  deploying  a main  chute  in  a design  limit  environment,  the  drogue  chute  was  reefed  to  27 
percent  full  open.  Because  of  the  resulting  slow  deployment  velocity  a phenomenon  called  "inflation 
overtake"  occurred  (Fig.  21).  When  this  happens  the  parachute  begins  to  inflate  prior  to  being  fully 
extracted  from  the  deployment  bag  resulting  in  contact  between  the  parachute  and  container.  In  Test  2, 
the  result  was  several  torn  horizontal  ribbons  in  one  gore  and  in  the  vicinity  of  the  canopy  skirt. 

Although  many  of  the  problems  experienced  were  related  to  test  peculiar  conditions  or  configura- 
tions, a good  understanding  was  gained  relative  to  aerodynamic  sensitivities  to  changes  from  the  base- 
line design.  This  understanding  has  already  enabled  some  modifications  to  the  decelerator  subsystem  to 
accommodate  unforeseeable  changes  in  the  SRB  design.  However,  of  primary  importance,  the  drop  test  pro- 
gram established  the  needed  confidence  that  the  subsystem  was  ready  for  qualification  testing  on  the 
actual  Space  Shuttle  flights. 


CURRENT/FUTURE  CHALLENGES  FOR  SRB  RECOVERY 


♦Although  a recovery  system  has  been  successfully  developed  for  the  Space  Shuttle  SRB,  both  planned 
and  proposed  changes  in  the  booster  design  are  presenting  new  challenges.  For  instance,  the  reentry 
center  of  gravity  has  already  migrated  16  in.  beyond  the  original  aft  limit  established  for  recovery 
system  design.  This  movement  is  primarily  a result  of  deleting  development  flight  instrumentation. 
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adding  approximately  1000  lb  of  structural  reinforcement  in  the  aft  skirt  region  to  take  higher  than 
expected  water  impact  loads,  and  reducing  the  motor  segment  weight.  To  compensate  for  the  hotter  tra- 
jectory resulting  from  the  more  tail  first  reentry,  some  reconfiguring  of  the  parachute  sequencing  and/ 
or  reefing  will  most  likely  be  required. 

An  alternative  to  structurally  strengthening  the  booster  aft  skirts  is  to  reduce  the  water  impact 
velocity.  This  approach,  currently  planned  for  the  twelth  Shuttle  flight,  will  require  the  development 
of  a larger  main  parachute. 

Another  major  challenge  will  be  the  development  of  a new  drogue  and  pilot  parachute  system  for  the 
planned  filament  would  case  SRB.  This  booster,  although  some  30,000  lb  lighter  at  burnout  than  the 
current  steel  case  SRB,  will  nonetheless  have  more  stringent  design  requirements. 

LARGER  MAIN  PARACHUTE 

The  larger  main  parachute  system  will  consist  of  a cluster  of  three  136-f t-diameter  parachutes  of 
similar  design  and  construction  to  the  115-ft  chutes.  This  size  parachute  will  provide  a reduction  in 
nominal  water  impact  velocity  from  87  to  75  ft/sec  and  can  be  contained  within  the  volume  available  in 
the  frustum. 

Figures  22  and  23  provide  a status  of  parachute  system  development  relative  to  size  versus  peak 
load  and  dynamic  pressure  at  deployment  respectively.  Included  for  comparison  are  the  Shuttle  drogue 
and  main  parachutes.  These  charts  illustrate  that  the  larger  main  parachute  system  will  be  stretching 
the  boundary  of  parachute  technology  with  respect  to  a combination  of  size,  load,  and  deployment  condi- 
tions. State-of-the-art  design  techniques  can  still  be  utilized,  however,  and  the  development  risk  is 
considered  to  be  low. 

A three-drop  development  test  program  is  planned  utilizing  the  DTV  shortened  by  54  in.  to  reduce 
B-52  hook  loads.  These  tests  will  be  performed  at  the  Naval  Weapons  Centers,  China  Lake,  California. 

FILAMENT  WOUND  CASE  PARACHUTES 

The  filament  wound  case  SRB  is  being  developed  to  reduce  weight  for  high  performance  Shuttle 
missions.  This  booster,  although  externally  similar  to  the  steel  case,  is  some  30,000  lb  lighter  at 
burnout  and  has  a center  of  gravity  almost  3 ft  further  aft.  Because  of  the  more  aft  center  of  gravity, 
the  booster  trim  angle  is  increased  about  10  deg  (more  tail  first)  causing  a substantial  drag  loss  and 
decrease  in  booster  deceleration.  This  results  in  near  sonic  conditions  at  drogue  deployment  with 
dynamic  pressure  above  900  psf.  One  method  available  to  improve  the  deployment  conditions  and  currently 
baselined  is  to  jettison  the  high  performance  motor  nozzle  extension  at  apogee.  This  provides  a blunter 
configuration  and  increases  reentry  drag  which  lowers  the  deployment  Mach  number  to  approximately  0.95 
and  dynamic  pressure  to  715  psf. 

The  greatest  challenge  for  the  development  of  this  system  will  be  to  devise  a development  test 
program  that  is  both  meaningful  and  cost  effective  which  will  verify  that  the  deployment  system  will 
function  properly  in  a high  Mach,  high  dynamic  pressure  environment.  A combination  of  rocket  sled  and 
air  drop  tests  is  currently  planned  to  accomplish  this  end. 


SUMMARY 


The  challenge  of  developing  the  recovery  system  for  the  Space  Shuttle  SRB  has  been  successfully 
met  as  demonstrated  by  both  development  air  drop  tests  and  flight  experience.  The  inherent  aerodynamic 
characteristics  of  the  reentering  SRBs  have  been  utilized  to  significantly  diminish  the  requirements  on 
the  parachute  system.  The  parachute  system  itself  has  been  systematically  optimized  through  wind 
tunnel,  rocket  sled  and  air  drop  tests  to  minimize  development  costs  and  maximize  overall  reliability. 

A similar  approach  using  the  current  system  data  base  as  a foundation  can  now  be  used  to  develop 
recovery  systems  to  meet  future,  more  stringent  Space  Shuttle  recovery  system  requirements. 
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TABLE  I.  PRIMARY  DROP  TEST  OBJECTIVES  MATRIX 
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Figure  1.  SRB  Recovery  Sequence  of  Events. 
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Figure  2.  Parachute  Locations  in  SRB. 
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Figure  3.  Drogue  Deployment  Sequence. 
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INHERENT  BODY  DRAG  (HIGH  a) 


Figure  4.  SRB  High  Altitude  Deceleration  Concepts. 


WATER  ENTRY  VELOCITY  (FT/SEC) 

Figure  5.  Deceleration  System  Weight. 


MACH  NUMBER 

Figure  6.  Wind  Tunnel  Versus  Flight  Reynolds  Number. 
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PITCHING  MOMENT  COEFFICIENT  Cm  c G 


Figure  7.  Effect  of  Model  Support  Method  on  Pitching  Moment  Coefficient. 


a.  SIDE  MOUNT  STRUT 


Figure  8.  Typical  Sting  Arrangements  for  Determining  Sting  Effects. 
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Figure  9.  MSFC  HRWT  Side  Strut  With  Dummy  Nose  Sting. 
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Figure  10.  Sting  Corrected  Pitching  Moment  Coefficients. 


Figure  11.  Candidate  Drogue  Deployment  Methods  Wind  Tunnel  Tested. 
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Figure  12.  Drogue  Deployment  Test  Hardware. 
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Figure  14.  Sled  Test  Configuration  (80-Degree  Test). 
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Figure  15.  Nose  Cap  Ejection  Sequence  (80-Degree  Sled  Test). 


I 


I 


I 


< 


1.  RELEASE  DTV  FROM  B-52.  T - 0 *. 

2.  FIRE  DROGUE  GUN.  T - 3.5  t. 

3.  DEPLOYED  VANE  CHUTE.  T - 3.8  *. 

4.  SEPARATE  EXTRACTION  CHUTE  COVER.  T - 4.5  *. 

5.  DEPLOYED  NOSE  CAP  EXTRACTION  CHUTE. 

T • 5.17  i.  |^13 

6.  SEPARATE  NOSE  CAP,  T - 19.20  *. 

7.  DEPLOYED  PILOT  CHUTE/DROGUE  CHUTE 
RELEASE.  T - 19.6  *. 

8.  DEPLOYED  DROGUE  CHUTE.  T - 20.55  •. 

9.  DROGUE  RETRIEVAL  LINE  VANE  CHUTE/FLOAT 
DEPLOYMENT.  T - 20.85  i. 

10.  DROGUE  FIRST  STAGE  DISREEF.  T - 27.41  t. 

11.  DROGUE  SECOND  STAGE  DISREEF.  T - 32.41  *. 

12.  FRUSTUM  SEPARATION,  T-  37.42*. 

13.  DEPLOYED  MAIN  CHUTE  CLUSTER.  T - 39.75  *. 

14.  MAIN  CLUSTER  FIRST  STAGE  DISREEF, 

T - 49.40  *. 

15.  MAIN  CLUSTER  SECOND  STAGE  DISREEF. 

T - 56.40  i. 

16.  FRUSTUM  IMPACT.  T - 203.6  ». 

17.  DROP  TEST  VEHICLE  IMPACT.  T - 216.5  *. 


115 


T 

5 


16 


T 

10 


1U. 


DOWN  RANGE  DISTANCE  (1000  FT) 


Figure  17.  Comparison  of  DTV  and  SRB  Size. 


Figure  18.  Typical  Drop  Test  Sequence  (Test  5), 
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Figure  20.  Drog  Test  Drogue  Deployment  Anomalies. 
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Figure  19.  Drogue  an  Single  Main  Full 
Open  Drag  Performance. 


INFLATION  OVERTAKE  (SINGLE  MAIN) 

Figure  21.  Inflation  Overtake  During 
Single  Main  Test. 
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PARACHUTE  DIAMETER 


Figure  22.  Parachute  Experience,  Peak  Loads. 


a 

X 

Q 

< 

QC 

< 


__  1 

1 

1 

ISTING  SYSTEMS 
)N  PARACHUTES 
SAIL  PARACHUTES 
> PARACHUTES 
NRACHUTES  IN  CLUSTER 

L 

/ 

□ 

V 

EX 

Q RiBBC 
□ RING! 
A SOLIC 
( ) NO.  Pi 

L. 

A 

(6) 

j 

□E 
U (2) 

A 

(3U 

? 

0,6 

A 

© DROC 
© MAIN 
0 MAIN 

SRB 

SUE 

1 - 115  FT. 
1 - 136  FT. 

L ■ j 

(51 

(3)[ 

H 

o'21 

Q 

(3) 

of  0 

O 

100  1,1 

300  10, 

000 

DYNAMIC  PRESSURE  ~ PSF 


Figure  23.  Parachute  Experience,  Deployment  Dynamic  Pressure. 
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ABSTRACT 


The  major  aerodynamic  design  challenge  at  the  beginning  of  the  United  States  Space 
Transportation  System  (STS)  research  and  development  phase  was  to  design  a vehicle  that  would  fly  as 
a spacecraft  during  early  entry  and  as  an  aircraft  during  the  final  phase  of  entry.  The  design  was 
further  complicated  because  the  envisioned  vehicle  was  statically  unstable  during  a portion  of  the 
aircraft  mode  of  operation.  The  second  challenge  was  the  development  of  preflight  aerodynamic 
predictions  with  an  accuracy  consistent  with  conducting  a manned  flight  on  the  initial  orbital 
flight. 

This  paper  presents  a brief  history  of  the  early  contractual  studies  highlighting  the  technical 
results  and  management  decisions  influencing  the  aerodynamic  challenges.  The  configuration 
evolution  and  the  development  of  preflight  aerodynamic  predictions  will  be  reviewed.  The  results 
from  the  first  four  test  flights  shows  excellent  agreement  with  the  preflight  aerodynamic 
predictions  over  the  majority  of  the  flight  regimes.  The  only  regimes  showing  significant 
disagreement  is  confined  primarily  to  early  entry,  where  prediction  of  the  basic  vehicle  trim  and 
the  influence  of  the  reaction  control  system  jets  on  the  flow  field  were  found  to  be  deficient. 
This  paper  concludes  with  an  analysis  of  postflight  results  to  attempt  to  explain  these  prediction 
deficiencies . 


INTRODUCTION 


A traditional  phased  approach  was  used  in  the  programmatic  design  evolution  of  the  Space 
Shuttle.  The  concept  evaluation  phase  (Phase  A)  contractural  studies  were  conducted  in  1969.  The 
Phase  B concept  definition  phase  extended  over  approximately  2 years  beginning  in  mid  1970.  The 
research  and  development  phase  (Phase  C)  and  the  production  and  flight  test  phase  (Phase  D)  began 
with  selection  of  Rockwell  International  as  prime  contractor  in  August  1972. 

The  following  sections  begin  with  background  information  which  presents  a brief  review  of  the 
Phase  A and  B studies.  The  study  results  and  management  decisions  which  influenced  the  aerodynamic 
design  are  highlighted. 

The  remainder  of  the  paper  addresses  the  challenges  facing  the  aerodynamic  analyst  at  the 
beginning  of  Phase  C & D,  the  approach  used  in  attacking  these  challenges,  and  the  success  with 
which  these  challenges  were  conquered.  The  paper  concludes  with  a review  of  the  postflight  analysis 
activity . 
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NOMENCLATURE 


ACRONYMS 


ADDB  Aerodynamic  Design  Data  Book 

AFFTC  Air  Force  Flight  Test  Center 

AEDC  Arnold  Engineering  Development  Center 

ALT  Approach  and  Landing  Test 

ARC  NASA  Arne 8 Research  Center 

AS I Aero  Stick  Input 

ATP  Authority  to  Proceed 

CDR  Critical  Design  Review 

DFRC  Dryden  Flight  Research  Center 

EAFB  Edwards  Air  Force  Base 

ETR  Eastern  Test  Range 

FCF  First  Captive  Flight 

FCS  Flight  Control  System 

FMOF  First  Manned  Orbital  Flight 

GN&C  Guidance,  navigation,  and  control 

JSC  NASA  Johnson  Space  Center 

KSC  NASA  Kennedy  Space  Center 

LaRC  NASA  Langley  Research  Center  (also  LRC) 

LTV  Ling-Temco-Vought  Corporation 

MSFC  Marshall  Space  Flight  Center 

NASA  National  Aeronautics  and  Space  Administration 

OADB  Operational  Aerodynamic  Data  Book 

OFT  Orbital  flight  test 

OML  Outer  Moldline 

OMS  Orbital  Maneuvering  System 

OV  Orbital  Vehicle 

PDR  Preliminary  Design  Review 

PRR  Program  Requirements  Review 

PTI  Programmed  Test  Input 

PWT  Propulsion  Wind  Tunnel 

RCS  Reaction  Control  System 

RSI  Reusable  Surface  Insulation 

SEB  Source  Evaluation  Board 

SRR  Systems  Requirements  Review 

SSME  Space  Shuttle  Main  Engine 

STS  Space  Transportation  System 

TAEM  Terminal  Area  Energy  Management 

TPS  Thermal  Protection  System 

TWT  Transonic  Wind  Tunnel 

UPWT  Unitary  Plan  Wind  Tunnel 

VAFB  Vandenberg  Air  Force  Base 

VKF  Von  Karman  Facility 

WTR  Western  Test  Range 


SYMBOLS 


Reference  wing  span,  ft 
Axial  force  coefficient 

Drag  force  coefficient 

Lift  coefficient 

Rolling  moment  coefficient 

Ef fective-dihedral  parameter,  per  degree 

Aileron  roll-control  effectiveness,  per  degree 

Rolling  moment  coefficient  derivative  with  respect  to  rudder,  per  degree 
Pitching  moment  coefficient 
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c 

m 


a 


eg 

h 

L/D 


M 


Longitudinal  static  stability  parameter,  per  degree 
Elevon  pitch  control  effectiveness,  per  degree 

Normal  force  coefficient 
Yawing  moment  coefficient 

Directional-stability  parameter,  per  degree 
Yawing  moment  due  to  aileron  deflection,  per  degree 

Rudder  yaw-control  effectiveness,  per  degree 

Side-force  coefficient 

Side-force  coefficient  derivative  with  respect  to  sideslip,  per  degree 

Side-force  coefficient  derivative  with  respect  to  aileron,  per  degree 

Side-force  coefficient  derivative  with  respect  to  rudder,  per  degree 

Factor  of  proportionality  in  linear  viscosity-temperature  relation 

Center  of  gravity,  inch 
Altitude,  ft 
Lift-to-drag  ratio 
Reference  body  length,  107.525  ft 

Free-stream  Mach  number 


MAC  Mean  aerodynamic  chord,  also  c,  39.568  ft 

m Mass  flow,  lbm/sec 

m. 

^ RCS  jet  mass  flow  ratio 

&oo 

n.  Number  of  RCS  jets  firing 

2 

q Dynamic  pressure,  lb/ft 

2 

Free-stream  dynamic  pressure,  lb/ft 
R^  Reynolds  number 

2 

S Reference  area,  2,690  ft 

V Velocity 

Design  touchdown  speed 


\T  Viscous  interaction  parameter 

x Characteristic  length,  ft 

'jC  Viscous  interaction  parameter 

a Angle  of  attack,  deg 

3 Angle  of  sideslip,  deg 

6^  Aileron  deflection  angle,  (left  elevon  - right  elevon  )/ 2,  deg 

6fiF  Bodyflap  deflection,  positive  for  trailing  edge  down,  deg 

Elevator  deflection,  positive  for  trailing  edge  down,  (left  elevon  + right  elevon)/2,  deg 

6 Rudder  deflection,  deg 

K 

6 Speedbrake  deflection,  deg 

bfi 

A Sweep  angle,  deg 

X Taper  ratio 

p Mass  density  of  air 

(j)  Momentum  parameter  (lbf) 

cj>  Bank  angle,  deg 
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<D. 

J 


cp 


RM 


JI 


SFJ 


YM 


JI 


SFJ 


SF 


JI 


SFJ 


PM 


JI 


SFJ 


RM 


JI 


DFJ 


RCS  jet  stream  momentum  ratio 

Longitudinal  center  of  pressure,  inch 

Rolling  moment  interaction  due  to  side  firing  jets 

Yawing  moment  interaction  due  to  side  firing  jets 
Side  force  interaction  due  to  side  firing  jets 
Pitching  moment  interaction  due  to  side  firing  jets. 
Rolling  moment  interaction  due  to  down-firing  jets 

Incremental  value 


SUBSCRIPTS 


j Jet  exit  conditions 

00  Free-stream  conditions 

s Spanwise  shock  location 


BACKGROUND 

The  Space  Transportation  System  (STS)  was  initiated  with  the  "Phase  A"  conceptual  design 
contracts  in  1969.  These  contracts  studied  various  methods  of  producing  a completely  reusable 
spacecraft  system  capable  of  a runway  landing.  A typical  concept  is  shown  in  figure  1.  The  results 
of  the  Phase  A studies  led  to  the  selection  of  a two-stage,  completely  reusable  vehicle  as  the  focus 
for  "Phase  B"  contractual  studies.  The  majority  of  the  studies  addressed  a first  stage  manned 
"flyback"  booster  in  combination  with  an  Orbiter  second  stage  as  shown  in  figure  2.  Subsequent  to 
staging,  the  flyback  booster  utilized  air  breathing  engines  to  return  to  the  launch  site  for  a 
runway  landing.  The  Orbiter  would  continue  the  launch  phase  until  low  earth  orbit  was  achieved. 
Following  a typical  on-orbit  mission  of  5 to  7 days,  the  Orbiter  would  re-enter  the  Earth's 

atmosphere  at  a high  angle  of  attack  (up  to  60°),  ultimately  landing  on  a runway  much  like  a 
conventional  airplane.  Midway  through  Phase  B,  estimates  of  system  development  costs  indicated  that 
the  peak  yearly  funding  requirements  for  the  parallel  development  of  two  manned,  fully  reusable 
vehicles  would  not  be  a viable  programmatic  approach.  During  this  time,  the  second  stage  fuel  tanks 
were  removed  from  the  Orbiter  to  minimize  the  impact  of  any  Orbiter  weight  growth  during  program 
development . 


In  the  final  months  of  Phase  B,  a parallel-burn  concept  was  selected.  This  concept  consisted 
of  the  simultaneous  burn  of  both  the  solid  rocket  boosters  (SRB)  and  the  three  liquid-fueled  Space 
Shuttle  main  engines  (SSME).  The  two  SRBs  assisted  lift-off  and  the  initial  ascent  flight.  The 
SSMEs,  fed  by  an  expendable  external  tank  (ET),  continued  to  burn  until  near  orbital  insertion.  The 
orbital  maneuvering  system  (OMS)  engines  provided  the  additional  delta-velocity  required  for  orbital 
insertion.  Figure  3 shows  a Rockwell  configuration,  which  is  typical  of  the  four  parallel-burn 
configurations  proposed  for  the  Phase  C & D contract. 


As  a result  of  the  Phase  B efforts,  the  Shuttle  configuration  shown  in  figure  4 was  selected 
for  the  design  and  development  phase.  It  was  a partial  ly-reusable  vehicle  with  a parallel-burn 
propulsion  system  consisting  of  recoverable  SRB's  and  an  expendable  ET  used  to  supply  fuel  to  the 
three  main  engines  of  the  completely  reusable  Orbiter. 

In  addition  to  defining  the  concept  for  the  Phases  C & D contract,  Phase  B studies  resulted  in 
several  programmatic  decisions  which  significantly  influenced  the  aerodynamic  design  of  the  Space 
Shuttle  Orbiter. 


The  most  significant  Phase  B decision  was  the  selection  of  the  reusable  surface  insulation 
(RSI)  system  rather  than  a hot-structure  system  for  protection  from  entry  heating.  This  RSI  design 

dictated  that  the  initial  entry  angle  of  attack  (a)  should  be  as  high  as  possible  (30°  to  50°)  to 
minimize  re-entry  heating.  The  U.S.  Air  Force  requirement  of  a 1 100-nautical  mile  (2037-kilometer) 

crossrange  dictated  that  0t  be  30°  or  lower  in  order  to  achieve  the  required  hypersonic  L/D.  To 
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reduce  re-entry  heating,  thereby  increasing  lifetime  of  the  RSI,  an  a profile  of  40°  was  chosen  for 
those  missions  not  requiring  the  high  crossrange. 

Another  Phase  B decision  affecting  the  future  aerodynamic  design  was  to  provide  for  a 
completely  computer-controlled,  automated  entry.  This  permitted  the  design  of  an  entry  flight 
control  system  (FCS)  to  artificially  provide  the  required  vehicle  stability  and  the  proper  handling 
qualities.  Traditionally,  a relatively  large  empennage  is  required  to  provide  the  requisite  vehicle 
directional  stability.  However,  augmentation  of  the  aerodynamic  stability  through  the  FCS  permits 
the  design  of  a smaller  empennage,  thus  providing  a significant  reduction  in  vehicle  weight. 

Initially  in  Phase  B there  was  not  a design  landing  velocity  on  which  to  size  the  wing , the 
major  weight  driver  of  the  Orbiter.  As  a consequence,  it  was  difficult  to  make  relative  weight 
comparisons  among  the  various  contractor  designs.  Midway  through  the  Phase  B effort,  NASA  defined  a 
subsonic  "design"  velocity  which  was  to  be  used  to  size  the  Orbiter  wing.  This  design  velocity, 
later  referred  to  as  the  design  landing  velocity,  was  defined  as  the  trimmed  velocity  at  an  angle  of 
attack  equivalent  to  tail  scrape  angle  at  touchdown.  A design  velocity  of  165  knots  (306  km/hr)  was 
chosen  since  man-in-the-loop  simulations  indicated  this  velocity  produced  actual  touchdown 
velocities  of  180-190  knots  (334-352  km/hr).  Touchdown  velocities  of  this  magnitude  were  well 
within  the  state  of  the  art  in  landing  gear  systems.  This  criteria  was  used  throughout  the 
remainder  of  the  development  program. 

As  an  end  item  product  for  Phase  B each  contractor  was  required  to  estimate  the  amount  of  the 
Phase  C & D wind  tunnel  testing  that  would  be  required  for  detail  design  and  development.  In 
reviewing  these  estimates,  it  became  obvious  that  the  aerodynamicist  would  be  faced  with  properly 
analyzing,  verifying,  and  documenting  the  largest  wind  tunnel  development  program  ever  undertaken. 
Using  these  contractor  estimates,  NASA  established  the  Source  Evaluation  Board  (SEB),  a total 
baseline  wind  tunnel  program  of  32,000  hours.  Proposals  of  the  four  contractors  called  for  programs 
ranging  from  27,000  to  50,000  hours.  The  actual  program  ultimately  accumulated  46,000  hours  for  the 
Phase  C & D effort. 

Although  not  directly  related  to  the  aerodynamic  design,  two  program  management  decisions  were 
made  at  the  beginning  of  Phases  C & D which  significantly  affected  the  magnitude  of  the  challenge  to 
the  aerodynamicist  s . The  first  decision  was  to  baseline  the  Orbiter  systems  configuration  at  the 
Authority  To  Proceed  (ATP)  milestone.  Thereafter,  the  only  design  changes  permitted  were  those 
which  were  required  to  fix  critical  system  design  problems.  The  Orbiter  systems  baseline  included 
not  only  the  vehicle  outer  mold  line  (OML)  configuration,  but  guidance,  navigation,  and  control 
(GN&C)  systems  and  other  subsystems.  The  second  decision  was  to  fly  a manned,  orbital  mission  on 
the  initial  flight  of  the  Space  Shuttle  system.  This  philosophy  of  permitting  only  mandatory  design 
changes  (which  became  known  as  "make-work")  significantly  influenced  the  management  of  the 
aerodynamic  and  FCS  development. 


THE  CHALLENGES 


Strongly  influenced  by  the  economic  and  programmatic  decisions  previously  discussed,  three 
major  aerodynamic  challenges  emerged. 

The  first  challenge  was  the  aerodynamic  design  of  a spacecraft /aircraft  that  could  fly  through 
the  entire  atmospheric  flight  regime.  The  design  had  to  satisfy  the  conflicting  requirements  of  a 
spacecraft-like  re-entry  and  a aircraft-like  runway  landing.  It  was  to  be  the  first  winged  vehicle 
to  fly  through  the  hypersonic  speed  regime,  providing  the  first  real  test  of  experimental  and 
theoretical  technology  of  high  speed  flight.  No  design  precedents  existed  to  help  establish  the 
design  requirements  of  such  a vehicle.  Yet,  the  design  had  to  satisfy  the  conflicting  aerodynamic 
characteristics  of  the  various  flight  regimes  as  well  as  satisfying  the  requirements  of  a completely 
automated,  multi-mode  flight  control  system. 

The  second  challenge  was  the  preflight  prediction  of  the  aerodynamic  characteristics  of  a 
complex  vehicle  with  an  accuracy  consistent  with  establishing  sufficient  confidence  to  conduct  the 
first  orbital  flight  with  a manned  vehicle.  This  required  the  identification  of  the  proper 
aerodynamic  similarity  parameters  and  overcoming  the  unknowns  of  the  hypersonic  wind  tunnel 
facilities.  It  called  for  the  efficient  conduction  and  analysis  of  the  most  extensive  wind  tunnel 
program  ever  undertaken.  And  finally,  in  order  to  ensure  consistency  of  design,  it  required  careful 
configuration  management  of  a continuously  evolving  aerodynamic  data  base  to  ensure  that  at  any  one 
point  in  time  all  systems  and  subsystems  were  using  the  same  set  of  aerodynamics. 


213 


Finally,  the  third  challenge  was  the  technical  management  of  the  aerodynamic  subsystem,  which 
consisted  of  the  following  elements: 

a.  Integrating  and  focusing  the  efforts  of  a diverse  number  of  organizations  from  the 
NASA,  DOD,  and  industry  aerodynamic  communities. 

b.  Obtaining  the  support  and  ensuring  the  efficient  utilization  of  virtually  every  major 
wind  tunnel  facility  in  the  United  States. 

c.  Ensuring  the  proper  and  timely  interface  with  the  other  Space  Shuttle  systems  and 
subsystems . 

This  paper  will  primarily  address  the  first  two  challenges,  which  are  technical.  Although  the 
third  challenge,  technical  management,  is  indirectly  addressed,  more  insight  into  this  challenge  may 
be  found  in  reference  1. 


THE  APPROACH 


The  Approach  Section  reviews  the  rationale  the  aerodynamic  analyst  used  in  attempting  to 
conquer  the  aerodynamic  challenges.  The  section  begins  with  a review  of  the  design  criteria  used  to 
configure  the  Orbiter.  Following  this  initial  section,  the  program  schedule  will  be  delineated. 
The  section  concludes  with  an  extensive  review  of  the  aerodynamic  development. 

ORBITER  AERODYNAMIC  CRITERIA 


Aerodynamic  criteria  for  the  final  selected  configuration  dictated  that  the  vehicle  perform  as 
both  a spacecraft  and  an  aircraft  during  re-entry  (figure  5).  Accordingly,  the  external  features 
must  be  carefully  configured  to  (1)  provide  the  protection  and  versatility  required  for  orbital  and 
atmospheric  flight  and  (2)  the  aerodynamic  performance,  stability,  and  control  necessary  for  an 
unpowered  descent  and  landing.  The  aerodynamic  lines  must  ensure  acceptable  performance  foi  the 
hypersonic-to-subsonic  speed  range  and  provide  the  required  crossrange  and  touchdown  velocity. 

Aerodynamic  requirements,  as  shown  in  table  1,  were  developed  from  analysis  of  the  re-entry 
phase  of  the  mission.  The  angle  of  attack  during  initial  entry  was  established  by  the  RSI 
temperature  requirement.  The  center  of  gravity  (eg)  requirement  resulted  from  a NASA  survey  of 
potential  payload  users.  Aerodynamic  static  stability  was  not  required,  since  the  design  criteria 
permitted  stability  augmentation  by  the  FCS  to  meet  aircraft  flying  qualities  criteria.  Early  entry 
flight  simulations  identified  a FCS  requirement  for  longitudinal  static  stability  of  no  more  than  2% 

L (5.44  % MAC)  unstable  at  the  aft  eg.  These  requirements  defined  the  aerodynamic  design  criteria 
B 

for  pitching  moment  characteristics.  The  subsonic  lift-to-drag  ratio  (L/D)  was  set  by  the  minimum 
value  necessary  for  a safe  landing. 

The  final  Orbiter  configuration,  as  shown  in  figure  6,  evolved  from  a series  of  program  and 
technical  refinements  directed  to  achieve  the  vehicle  yielding  the  best  combination  of  performance 
and  cost.  This  evolution  is  discussed  further  in  a later  section.  Figure  7 presents  the  general 
sizing  criteria  for  the  various  components  of  the  Orbiter.  The  double-delta  wing  planform,  combined 
with  a fuselage  of  moderately  low  fineness-ratio  (approximately  five),  minimizes  the  interference 
heating  effects,  provides  the  required  hypersonic  crossrange,  and  possesses  an  acceptable  trim  and 
stability  range  over  the  flight  Mach  number  range. 

The  subsonic  design  velocity  was  increased  to  171  knots  (88  m/sec)  in  order  to  reduce  the 

Orbiter  wing  size  thereby  reducing  vehicle  weight.  The  leading  edge  sweep  angle  (A  ■ 45°)  and 
aspect  ratio  (2.265)  were  selected  on  the  basis  of  aerothermodynamic  trade  studies  to  provide  the 
design  touchdown  speed  for  a eg  at  the  forward  limit  with  minimum  wing  size.  This  optimized  the 
wing  leading  edge  thermal  protection  system  for  a reuse  cycle  of  100  flights  before  major  rework. 

The  fuselage  was  designed  to  accommodate  a variety  of  payloads  and  to  house  the  crew.  It  also 
was  designed  to  contain  the  propulsion  systems  for  launch  and  orbital  maneuvering  as  well  as  provide 
a support  structure  for  the  main  engines.  The  size  of  the  payload  bay  was  a contract  specification. 
The  size  of  the  base  of  the  fuselage  was  dictated  by  the  packaging  of  the  SSME's.  The  forward 
fuselage  was  dictated  by  packaging  of  the  crew  compartment.  Nose  camber  and  cross  section,  along 
with  upward  sloping  forebody  sides,  were  selected  to  improve  hypersonic  pitch  trim  and  directional 
stability.  And  in  conjunction  with  wing-body  blending,  to  reduce  entry  heating  on  the  body  sides. 
Reaction  control  system  (RCS)  jets  for  entry  attitude  control  and  orbital  maneuvering  engines  were 
incorporated  in  pods  located  in  the  aft  body  fairings.  The  orbital  maneuvering  system  (QMS)  pods 
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were  sized  for  the  OMS  tankage.  The  bodyflap,  originally  sized  to  provide  thermal  protection  for 
the  SSME's  during  entry,  is  now  also  used  as  the  primary  pitch  trim  device. 

The  vertical  tail  was  sized  to  provide  a low  speed  C of  0.0013  at  an  angle  of  attack  of  13° 

n3 

9 

about  a center  of  gravity  located  at  the  aft  limit.  It  has  a reference  area  of  413.25  ft  (38.39 
2 

m ) including  the  rudder/speedbrake . The  section  profile  consists  of  a 5°  half-angle  double-wedge 
airfoil.  The  rudder  is  split  along  the  Orbiter  plane  of  symmetry  to  provide  directional  stability 
augmentation  in  the  hypersonic/ supersonic  flight  regimes,  and  to  apply  drag  modulation  for  the 
subsonic  flight  phase,  approach,  and  landing. 


DEVELOPMENT  APPROACH 


The  Development  Approach  will  initially  address  the  development  schedule  followed  by  a review 
of  the  configuration  evolution. 


DEVELOPMENT  SCHEDULE 

Major  program  milestones  for  Phase  C & D are  illustrated  in  figure  8.  They  start  with  the  ATP 
in  August  1972  and  culminate  with  initial  operational  capability  in  1982  . The  Orbiter  concept  at 
ATP  was  a blended  delta  wing  vehicle  based  on  precontract  studies  and  configured  to  meet  initial 
Space  Shuttle  Program  requirements.  As  a result  of  a continuing  assessment  of  system  requirements 
and  technical  refinements  early  in  the  contract,  the  Orbiter  concept  was  modified  to  reduce  weight 
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and  decrease  program  and  operating  costs.  Refinements  in  the  aerodynamic  configuration  led  to  a 
double-delta  planform  incorporating  a more  efficient  lifting  surface  than  the  blended  delta.  The 
System  Requirements  Review  (SRR)  in  August  1973,  finalized  the  technical  requirements  for  the  Space 
Shuttle  systems  (i.e.,  the  total  vehicle,  its  elements,  and  their  ground  systems)  and  approved  the 
design  approach  of  the  vehicle  and  associated  support  equipment.  The  Preliminary  Design  Review 
(PDR)  cf  the  first  Orbiter  vehicle  (OV-101)  and  subsystems  for  the  approach  and  landing  flight  test 
(ALT)  program  were  completed  in  February  1974.  The  PDR  of  the  second  Orbiter  Vehicle  (OV-102) 
followed  in  March  1975.  OV-101  rollout  from  final  assembly  in  Palmdale,  California,  took  place  in 
September  1976.  The  ALT  Program  consisted  of  three  parts:  (1)  Orbiter/747  mated;  (2)  tailcone-on 
Orbiter  alone;  and  (3)  tailcone-off  Orbiter  alone.  The  vehicle  was  mated  to  the  Boeing  747  carrier 
aircraft  at  the  Dryden  Flight  Research  Center  (DFRC),  Edwards  Air  Force  Base,  and  the  first  captive 
flight  was  completed  in  February  1977  . The  first  ALT  flight  of  OV-101  from  the  Boeing  747  took 
place  on  August  12,  1977.  A detailed  review  of  the  ALT  program  is  presented  in  reference  4.  In 
March  1978,  OV-101  was  delivered  to  the  Marshall  Space  Flight  Center  (MSFC),  Alabama,  for  ground 
vibration  testing. 

Fabrication  and  assembly  of  OV-102,  the  first  orbital  vehicle,  began  in  1975,  and  the  Critical 
Design  Review  (CDR)  was  conducted  in  July  1977.  Rollout  of  OV-102  was  accomplished  in  March  1979  , 
with  delivery  to  Kennedy  Space  Center,  Florida  occurring  a few  weeks  later.  The  first  manned 
orbital  flight  was  conducted  in  April  1981.  The  official  Orbital  Flight  Test  (OFT)  program  was 
established  as  the  first  four  flights  (STS-1  thru  -4)  with  the  initial  operational  capability 
starting  with  STS-5  in  November  1982.  However,  aerodynamic  flight  test  maneuvers  are  planned 
through  STS-1 7. 


CONFIGURATION  EVOLUTION 

Stability,  control,  and  performance  requirements  for  the  Orbiter  vehicle  are,  for  the  most 
part,  established  by  the  entry  phase  of  the  mission.  On  the  other  hand,  design  airload  conditions 
are  primarily  driven  by  the  ascent  phase. 

Design  issues  keyed  to  achieving  the  proper  aerodynamic  balance  to  provide  stability,  control, 
and  center  of  gravity  envelope  during  the  entry  flight  regime  are:  (1)  wing  design,  (2)  wing-body 
integration,  and  (3)  integration  of  aerodynamic  and  flight  control  requirements.  Wing  design  was 
key  because  of  its  influence  on  vehicle  weight,  thermal  environment,  aerodynamic  stability,  buffet 
characteristics,  and  gliding  and  landing  performance  capability.  Wing-body  integration  was 
important  in  obtaining  a balanced  aerodynamic  configuration  capable  of  trim  and  control  over  the 
entire  speed  range,  and  in  minimizing  thermal  environment  due  to  interference  flow  effects. 
Fuselage  dimensions  were  largely  fixed  by  payload  size  and  packaging  efficiency  while  aerodynamic 
and  aero  thermodynamic  considerations  established  forebody  shape  and  local  contours.  Integration  of 
aerodynamic  control  requirements  was  of  major  importance  in  meeting  flying  quality  goals  in  all 
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flight  regimes,  and  minimizing  vehicle  weight  as  affected  by  control  surface  arrangement,  size,  and 
actuator  requirements. 

Prior  to  Shuttle  Program  "go-ahead"  in  August  1972,  NASA  funded  extensive  Shuttle  System  trade- 
off studies  (Phase  B contracts)  to  determine  the  following:  (1)  operational  cost  effectiveness;  (2) 
desired  configuration  and  geometry;  (3)  major  subsystem  definition;  (4)  configuration  drivers 
consisting  of  landing  speed,  payload  size  and  weight,  and  center  of  gravity  envelope;  (5)  entry 
crossrange  and  aerodynamic  heating;  (6)  stability  and  control  requirements;  and  (7)  flying 
qualities.  From  these  studies  emerged  a baseline  configuration  at  Shuttle  Program  ATP.  Following 
ATP,  further  trade  studies  were  conducted  by  JSC  and  the  prime  contractor  to  refine  the  baseline 

design.  Essentially  four  aerodynamic  configurations  were  evaluated  before  the  final  baseline 
design  was  selected. 

The  phasing  of  the  evolving  configuration  is  illustrated  in  figure  10.  The  Rockwell  blended 
delta  configuration  was  baselined  at  ATP,  with  only  "make-work"  design  changes  permitted  thereafter. 
The  vehicle  was  sized  for  a dry  weight  of  170,000  lb,  (77,110  kg)  and  landing  payload  of  40,000  lbs 
(18,144  kg).  Initial  wind  tunnel  tests  indicated  the  ATP  configuration  did  not  meet  the  landing 
performance  requirements.  Wing  optimization  to  meet  these  requirements  led  to  baselining  a 
configuration  for  the  December  1972  Program  Requirements  Review  (PRR). 

The  "make-work"  philosophy  was  interrupted  late  in  1972  by  a change  in  system  requiremement s 
prompted  by  NASA's  desire  to  reduce  the  operational  cost  per  flight.  This  requirement  update 
reduced  the  vehicle  dry  weight  to  150,000  lbs  (60,039  kg)  and  landing  payload  to  32,000  lbs  (14,515 
kg). 


In  addition  to  this  requirement  change,  Rockwell  was  directed  by  NASA  to  incorporate  the 
double-delta  wing  design.  A year  of  NASA  in-house  study  indicated  the  double-delta  wing  had 
exceptional  landing  performance.  In  addition  the  aerodynamic  stability  and  trim  could  be  adjusted 
by  modifying  the  lightly  loaded  forward  delta  (glove).  This  simple  control  of  aerodynamic  features 
allowed  the  design  of  the  main  delta  wing  box  to  be  frozen.  Any  eg  or  aerodynamic  stability 
problems  which  might  surface  during  program  development  could  then  be  corrected  by  glove 
modification  thereby  minimizing  program  impact. 

During  this  period,  the  maximum  utilization  of  uniform  dimension  tiles  was  baselined  in  an 
attempt  to  minimize  the  RSI  production  and  installation  costs.  Incorporation  of  this  "standard" 
tile  design,  led  to  a vehicle  whose  surface  was  composed  of  large  flat  areas,  limiting  curvature  to 
smaller  areas  between  the  flat  ones. 

These  changes  in  system  requirements  and  design  led  to  baselining  a new  configuration  for  the 
March  1974  PDR.  Initial  wind  tunnel  tests  of  this  PDR  configuration  indicated  the  configuration  was 
not  workable.  Aerodynamic  tests  showed  difficulty  in  providing  trim  capability  at  the  forward  eg  in 
the  supersonic  flight  regime.  Aeroheating  tests  indicated  the  blunt  fuselage  nose  resulted  in  early 
transitional  flow  and  high  temperatures  along  the  lower  body  surface.  Also  wing  incidence,  camber, 
and  thickness  distributions  designed  for  maximum  subsonic  performance  led  to  local  fairings  on  the 
lower  wing  and  fuselage  surfaces  which  caused  high  local  heating.  These  findings  led  to  a 
configuration  modification  of  the  Orbiter  to  eliminate  these  deficiences. 

Ensuing  wind  tunnel  tests  indicated  the  revision  of  the  PDR  configuration  was  an  acceptable 
configuration.  After  minor  changes,  such  as  blunting  the  forward  portion  of  the  OMS  pod  to  allow 

the  aft  payload  bay  to  open  180°,  this  configuration  was  baselined  as  the  CDR  configuration  at  the 
OV-102  PDR  in  February  1975. 

After  a flurry  of  configuration  development  activity  in  the  first  7 months  of  the  Phase  C & D 
contract,  the  aerodynamic  configuration  remained  relatively  stable  allowing  the  aerodynamic  effort 
to  focus  on  the  development  and  verification  of  the  preflight  aerodynamic  predictions. 

AERODYNAMIC  DEFINITION  APPROACH 

Conventional  flight  test  programs  call  for  the  incremental  expansion  of  the  flight  envelope  to 
demonstrate  the  design  capability  of  the  aircraft.  This  is  not  feasible  with  the  Shuttle  vehicle. 
Once  the  Shuttle  is  launched,  it  is  committed  for  flight  over  the  complete  mission  profile  from 
ascent  to  orbital  insertion,  deorbit,  re-entry,  and  landing.  Predicted  flight  characteristics  must 
be  based  on  aerodynamic  data  derived  from  theory,  ground  testing,  and  analysis.  Careful  attention 
has  been  given  to  the  interactions  between  flight  control  systems  design  and  aerodynamic 
characteristics.  Because  of  these  considerations  great  care  had  to  be  exercised  in  the  development 
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of  the  preflight  aerodynamic  estimates.  This  section  of  this  paper  addresses  the  management, 
development  and  verification  of  the  preflight  aerodynamic  predictions. 

TYPICAL  ORBITER  MISSION 

At  an  altitude  of  approximately  600,000  ft,  the  Orbiter  is  designed  to  perform  an  unpowered, 

gliding  re-entry  at  an  angle  of  attack  of  approximately  40°.  The  angle  of  attack  is  modulated 
depending  upon  the  crossrange  requirements.  Downrange  modulation  is  achieved  by  periodically 
performing  bank  reversals  across  the  prescribed  ground  track.  Figure  11  presents  a typical  re-entry 
trajectory. 

Although  entry  interface  (El)  is  defined  as  400,000  ft  altitude,  a sensible  atmosphere  is  not 
reached  until  Mach  27  at  an  altitude  of  approximately  300,000  ft,  with  a dynamic  pressure  of  2 psf. 
Early  entry  stability  and  control  is  provided  primarily  by  the  aft-mounted  reaction  control  system 
(RCS ) jets,  (figure  12).  The  forward-mounted  jets  are  reserved  for  on-orbit  attitude  control  and 
ascent  aborts.  The  roll  and  pitch  jets  are  active  until  dynamic  pressures  of  10  and  20  psf, 
respectively,  are  obtained,  at  which  point  the  elevons  are  sufficiently  effective  to  provide  pitch 
and  roll  control.  The  yaw  jets  provide  stability  augmentation  until  the  vehicle  has  decelerated  to 
Mach  1 . 

A gradual  pitch  down  is  initiated  between  Mach  14  and  12.  By  Mach  2 the  vehicle  is  flying  at 

more  conventional  angles  of  attack  from  3°  to  10°.  Equilibirum  subsonic  gliding  flight  is  achieved 
at  an  altitude  of  approximately  40,000  ft.  The  approach  and  landing  interface  occurs  at  10,000  ft, 

and  the  vehicle  subsequently  reaches  a glide  slope  of  approximately  -19°.  Nominal  touchdown 
velocity  is  195  knots  with  a rollout  of  7,000  to  9,000  ft. 

ORBITER  FUNCTIONAL  CHARACTERISTICS 

The  functional  characteristics  of  the  Orbiter  are  presented  in  figure  13.  The  thick,  double- 
delta wing  is  configured  with  full  span  elevons,  comprised  of  two  panels  per  side.  Each  elevon 
panel  is  independently  actuated.  All  four  panels  are  deflected  together  as  an  elevator  for  pitch 
control  and  left  and  right  elevons  are  deflected  differentially  as  an  aileron  for  roll  control. 

The  bodyflap,  originally  designed  as  a heat  shield  for  the  SSMEs,  is  now  also  used  as  the 
primary  longitudinal  trim  device.  The  elevons  are  programmed  to  follow  a set  schedule  during  entry 
to  provide  the  optimum  aileron  effectiveness. 

The  vertical  tail  consists  of  the  fin  and  a split  rudder.  The  rudder  panels  are  deflected 
together  for  yaw  control  and  are  separated  to  act  as  a speedbrake  to  provide  for  subsonic  energy 
modulation.  The  speedbrake,  initially  closed  upon  entry  interface,  opens  fully  just  below  Mach  10, 
and  then  follows  a predetermined  schedule  until  Mach  0.9  is  reached.  The  rudder  is  not  activated 
for  yaw  control  until  Mach  3.5. 

PREFLIGHT  PREDICTION  REQUIREMENTS 

The  preceding  discussion  leads  to  the  conclusion  that  prediction  of  the  basic  aerodynamic 
characteristics  of  the  vehicle  are  required  from  Mach  0.2  through  27,  and  at  an  angle  of  attack 

range  from  near  0°  to  40°.  Figure  14,  which  delineates  utilization  of  the  vehicle  control 
effectors,  shows  that  predictions  of  aileron  and  elevon  effectiveness  would  be  needed  over  the  same 
M,  a range.  Rudder  power  needs  definition  below  Mach  3.5.  The  high  dynamic  pressure  to  be 
encountered  forced  consideration  of  structural  deformation  effects  on  aerodynamics.  Also  the 
effectiveness  of  the  RCS  would  have  to  be  determined  from  on-orbit  conditions  down  to  as  low  as 
50,000  ft  (Mach  1).  The  RCS  effectiveness  is  a function  of  jet  thrust,  plume  impingement  and  the 
vehicle  flow  field/plume  interaction  as  shown  in  figure  15. 

PREFLIGHT  WIND  TUNNEL  PROGRAM 

Key  to  the  Space  Shuttle  development  has  been  the  acquisition  of  wind  tunnel  test  data  to 
support  GN&C  design  and  evaluation  by  providing  a continuously  maturing  aerodynamic  data  base 
reflecting  configuration  and  subsystem  updates.  By  the  first  orbital  flight  (STS-1)  in  1981, 
approximately  46,000  total  wind  tunnel  test  hours  had  been  conducted  for  aerodynamics,  heat 
transfer,  and  structural  dynamics,  consisting  of  approximately  24,900  for  the  Orbiter  vehicle, 
17  ,200  for  the  mated  launch  configuration,  and  3,900  for  the  carrier  aircraft  program,  as  shown  in 
figure  16.  A total  of  101  models  have  been  built:  45  aerodynamic,  34  heat  transfer,  and  22 
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structural  dynamics.  All  wind  tunnel  testing  was  coordinated  with  and  approved  by  NASA  management 
at  JSC.  A detailed  review  of  the  history  and  management  of  the  wind  tunnel  program  may  be  found  in 
reference  1 . 


Orbiter  aerodynamic  test  hours  are  summarized  in  figure  17.  Approximately  38%  of  the  Orbiter 
aerodynamic  test  hours  were  utilized  in  the  subsonic  regime,  44%  in  the  transonic/supersonic  regime, 
and  18%  in  the  hypersonic  regime.  As  may  be  seen  from  figures  16  and  17,  the  Space  Shuttle  wind 
tunnel  program  was  by  far  the  largest  program  ever  undertaken  by  this  country.  Also  seen  in  figure 
17  is  an  additional  10,000  hours  of  testing  performed  by  Langley  for  special  investigations 
requested  by  Space  Shuttle  management. 

SELECTION  OF  SCALING  PARAMETERS 


In  order  to  accurately  simulate  flight  conditions  in  a wind  tunnel,  the  appropriate  similarity 
parameters  must  be  matched.  Traditionally,  Mach  number  and  Reynolds  number  are  the  key  parameters. 

Problems  in  flow  simulation^  occur  when  the  geometric  scaling  of  viscous  flow  is  important,  or  when 
coupling  between  the  viscous  surface  flow  and  the  external  flow  field  is  strong.  In  the  first  case, 
the  boundary  layer  can  be  considered  separately  from  the  inviscid  flow  field,  and  viscous  effects 
can  be  scaled.  This  holds  for  Mach  numbers  up  to  approximately  10.  It  is  well  known,  for  example, 
that  skin  friction  varies  with  Reynolds  number  in  a predictable  manner  and  can  be  scaled  to  flight 
conditions  from  suitable  wind  tunnel  results. 


For  Mach  numbers  greater  than  approximately  10,  a pressure  interaction  results  from  the  outward 
streamline  deflection  induced  by  a thick  boundary  layer,  and  the  viscous-invis cid  interaction  must 
be  considered.  For  this  case,  there  are  two  classical  simulation  parameters  commonly  considered: 

(1)  %' , the  viscous  interaction  parameter  introduced  by  Hayes  and  Probstein^ 


ooT  oo 


(2)  V',  the  vi 8 cou s parameter  introduced  by  Whitfield  and  Griffith 


where  M^  is  the  free-stream  Mach  number,  is  the  factor  of  proportionality  in  the  linear 
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viscosity-temperature  relation,  and  R is  the  free-stream  Reynolds  number  based  on  the  appropriate 
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characteristic  length  (x).  The  parameter  xw  is  the  relevant  parameter  for  the  local  effects 
(pressure  coefficient,  heat  transfer,  etc.)  in  both  the  strong  and  weak  interaction  cases;  whereas 
V'  is  the  relevant  parameter  in  terms  of  overall  integrated  effect.  For  Shuttle,  it  has  been 

OO 

observed  that  correlates  total  aerodynamic  coefficients  better  than  and  consequently,  was 

selected  as  the  hypersonic  simulation  parameter.  A detailed  discussion  of  the  use  of  these  scaling 
parameters  for  the  Space  Shuttle  is  presented  in  reference  10. 


Figure  18  shows  a comparison  between  flight  R and  and  the  simulation  capability  of 
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typical  wind  tunnels  used  to  develop  the  Orbiter  aerodynamic  data  base.  It  can  be  seen  that  the 
tunnel  capabilities  reasonably  match  flight  conditions  above  Mach  3.  It  should  be  noted  that 

although  flight  Reynolds  number  and  Mach  number  were  not  simulated  above  Mach  15,  if  is  the 
correct  similarity  parameter,  the  tunnel  prediction  of  aerodynamic  characteristics  should  be  good. 
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One  inadequacy  worth  noting  is  that  at  the  time  of  the  Shuttle  aerodynamic  development  (prior  to 
STS-1)  neither  experimental  facilities  nor  theory  could  accurately  predict  real  gas  effects. 

SIMULATION  OF  REACTION  CONTROL  JET  INTERACTION 


Early  entry  aerodynamic  characteristics  are  highly  influenced  by  interactions  between  the 
reaction  control  system  (RCS)  jet  plumes  and  the  local  flow  field  over  the  Orbiter  as  shown  in 
figure  15.  The  total  jet  effects  are  comprised  of  three  factors:  (1)  jet  thrust,  (2)  surface 
impingement,  and  (3)  jet  interaction  with  the  flow  field.  Impingement  and  interaction  effects  are 
interrelated.  Jet  interaction  was  obtained  from  wind  tunnel  testing  while  surface  impingement  was 
estimated  from  vacuum  chamber  tests  and  theory.  Coupling  is  present  between  the  plume  effects  and 
aerodynamic  surfaces,  and  between  the  jets  themselves. 


A series  of  scaled  model  RCS  nozzles  with  different  expansion  ratios  were  employed  during  the 

wind  tunnel  test  program.  General  Dynamics/Conva ir , under  contract  to  the  NASA  (NAS9-14095) , ^ 
developed  a method  whereby  the  experimentally-measured  induced  plume  effect  (surface  impingement 
plu 8 flow  field  interaction)  could  be  separated  into  two  component  parts  and  the  impingement  term 
extrapolated  to  flight  conditions.  To  obtain  a correct  modeling  of  the  reaction  control  system 
plume  effects  in  the  wind  tunnel,  it  was  necessary  to  observe  certain  scaling  criteria.  The  primary 
factors  for  consideration,  aside  from  dimensional  scaling,  are  plume  shape,  jet-to-f ree-stream 

momentum  ratio  (4>./<f)  ) and  mass  flow  rate  ratio  (m./m  ).  The  RCS  pitch  jets  (up  and  down  firing 

J 00  J 00 

jets)  correlated  better  with  momentum  ratio  whereas  the  yaw  jets  (side  firing  jets)  correlated 
better  with  mass  flow  rate  ratio. 


and 


These  scaling  parameters  are  defined  as: 
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A detailed  discussion  of  the  selection  of  these  scaling  parameters  is  presented  in  reference 


THE  WIND  TUNNEL  PROGRAM 

The  wind  tunnel  program  can  be  divided  into  three  phases.  These  phases  are  related  to  the 
development  schedule  as  illustrated  in  figure  10. 

The  first  of  these  phases  (Phase  I)  was  the  configuration  development  phase.  This  phase,  which 
covered  the  time  period  of  ATP  to  SRR,  addressed  ATP  configuration  refinement,  evaluation  of  the  PDR 
configuration,  and  definition  of  the  CDR  configuration. 

The  prime  contractor  devoted  the  majority  of  their  Phase  II  efforts  to  developing  and  verifying 
the  aerodynamic  characteristics  for  the  ALT/carrier  program  although  initial  development  testing  for 
the  OFT  program  was  also  performed.  These  latter  development  tests  were  directed  toward 
establishing  the  basic  stability  and  control  characteristics  across  the  Mach  range;  establishing 
control  surface  effectiveness  and  hinge  moments;  initial  RCS  testing;  and  viscous  interaction 
testing.  The  FCS  was  converging  on  a detail  design  during  the  Phase  II  time  period  and  concerns 
surfaced  regarding  the  sensitivity  of  the  FCS  to  nonlinear  aerodynamics.  In  order  to  investigate 
potential  nonlinearities,  JSC  management  requested  the  LaRC  to  supplement  the  contractor's  test 
program.  These  tests  investigated  the  following  areas:  (1)  non-linear  aerodynamic  characteristics 
of  the  basic  vehicle  and  its  control  surfaces;  (2)  aerodynamic  damping  characteristics;  (3)  control 
surface  interactions;  and  (4)  high  Mach/altitude  simulations.  In  addition,  the  possibility  of  high 
altitude  snap  roll  caused  by  asymmetric  separation  of  the  wing's  leeside  flow  field  was  explored. 
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The  final  phase  (Phase  III)  of  the  wind  tunnel  program  was  initiated  in  early  1978  to  verify 
the  predicted  aerodynamic  characteristics  of  the  final  vehicle  configuration  prior  to  the  first 
orbital  flight  (STS-1).  The  objectives  of  this  phase  were  to: 

a.  Verify  and/or  update  the  aerodynamic  characteristics  of  the  final,  "as  built" 
configuration  across  the  Mach  range  of  0.2  to  15. 

b.  Test  fine-cut  (small  increments)  in  Mach  number,  angle  of  attack,  angle  of  sideslip, 
and  control  surface  position  along  the  nominal  flight  trajectory. 

c.  Minimize  model-to-model  and  tunnel-to-tunnel  discrepancies. 

1 2 

The  final,  preflight  Aerodynamic  Design  Data  Book  (ADDB)  is  primarily  based  on  these  verification 
test 8.  The  verification  phase  consisted  of  three  parts: 

a.  Seven  initially  planned  verification  tests. 

b.  Five  anomaly  resolution  tests. 

c.  Five  supersonic/hypersonic  lateral-directional  nonlinearity  tests. 

The  complete  verification  phase  is  shown  in  figure  19. 

Two  high-fidelity  wind  tunnel  models,  of  2%  and  5%  scale,  were  designed  and  constructed  based 
on  the  March  1976  OV-102  configuration  drawings  to  ensure  accurate  modeling  of  all  aerodynamic 
surfaces  and  simulation  of  all  revelant  cavities  and  protuberances  as  shown  in  figure  20.  Although 
some  minor  changes  to  the  TPS  thicknesses  were  made  after  March  1976  , these  changes  were  closely 
monitored  to  ensure  that  there  were  no  aerodynamicly  significant  differences  between  the  wind  tunnel 
models  and  the  actual  flight  vehicle  OV-102. 

Part  1 of  the  verification  phase  consisted  of  the  wind  tunnel  tests  required  for  verification 
as  it  was  originally  conceived.  These  tests  covered  the  Mach  range  of  0.2  to  15  using  the  two  high- 
fidelity  models  without  planned  duplication  of  test  conditions  with  different  combinations  of  models 
and  facilities.  Several  additional  tests  and  considerable  analyses  were  required  to  actually 
complete  the  preflight  verification  process.  In  order  to  acquire  the  highest  quality  data  possible 
within  time  and  fiscal  constraints,  a test  team  was  established  for  each  test  consisting  of  the 
prime  contractor,  JSC,  and  facility  engineers,  co-chaired  by  the  JSC  and  the  prime  contractor  lead 
engineers.  This  team  followed  the  test  from  initiation  through  model  design  and  construction,  test 
plan  development,  conduct  of  tests,  and  analysis  of  results. 

The  design  of  the  verification  tests  drew  heavily  on  the  experience  and  results  of  a series  of 
wind  tunnel  tests  conducted  by  LaRC . These  tests  utilized  a 1.5-scale  model  (OV-101/140C 
configuration)  with  remotely  controlled  elevons.  They  were  conducted  to  investigate  transonic  and 
low  supersonic  lateral-directional  nonlinearities  and  showed  the  importance  of  obtaining  wind  tunnel 
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data  in  small  increments  and  of  utilizing  remotely  controlled  aerodynamic  surfaces.  Two  of  the 
major  benefits  of  testing  with  remotely  controlled  surfaces  are:  (1)  permits  efficient  acquisition 

of  small  increments  of  the  primary  variable  of  interest,  i.e.,  the  control  surface  position;  and  (2) 
permits  the  acquisition  of  more  accurate  data  by  "sweeping"  the  control  surface  position  while  other 
test  variables  are  held  constant. 

The  verification  phase  relied  heavily  on  the  NASA-Ames  Research  Center  (ARC)  wind  tunnel 
facilities,  as  had  the  development  test  phase.  Table  2 shows  the  utilization  of  facilities  for 
Phase  III. 

Although  Part  1 of  the  verification  tests  were  largely  successful,  initial  analysis  of  the  data 
from  these  tests  indicated  additional  wind  tunnel  tests  were  required  to  resolve  the  following  test 
anomalies : 


a.  Transonic  - resolve  blockage  and  shock  reflection  effects. 

b.  Supersonic  - verify  relatively  large  facility  (AEDC)  flow  tare  corrections. 

The  tests  shown  under  Part  2 in  figure  19  were  conducted  as  part  of  the  verification  tests  phase  to 
address  the  transonic  blockage/shock  reflection  and  supersonic  tare  correction  problems. 

The  quick-look  analysis  of  these  tests  still  did  not  provide  any  clear-cut  solutions  to  the 
original  problems.  Therefore,  in  July  1978,  the  Technical  Panel  for  Orbiter  Aerodynamics  was  formed 
at  the  request  of  the  JSC  Center  Director  to  address  these  problems.  The  objective  of  the  Panel  was 
to  expedite  the  analysis  of  the  Orbiter  aerodynamic  design  data  to  produce  a mature  data  base  that 
would  support  the  launch  of  the  first  manned  orbital  flight  planned  for  March  1980.  This  Panel  was 
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comprised  of  working-level  aerodynamicist s representing  expertise  from  ARC,  DFRC , LaRC,  JSC,  AFFTC , 
and  the  prime  contractor.  The  major  functions  of  the  Panel  were: 

a.  Recommend  and  conduct  wind  tunnel  tests. 

b.  Evaluate  and  recommend  the  most  valid  test  data  for  use  in  establishing  the  ADDB 
preflight  predictions. 

c.  Perform  an  independent,  detailed  analysis  of  critical  areas. 

d.  Perform  a thorough  review  of  the  proposed  ADDB  prior  to  publication  and  make 
recommendations  for  accceptance  or  change. 

e.  Obtain  Panel  consensus  that  the  ADDB  is  the  "best"  repr esentation  of  the  Orbiter 
aerodynamics . 

f.  Give  technical  approval  of  the  official  ADDB. 

The  results  of  a wind  tunnel  test  conducted  by  LaRC  to  assess  the  OV-102  configuration  showed 
that  there  were  no  significant  aerodynamic  differences  between  OV-101  and  OV-102.  As  a result,  the 
large  number  of  wind  tunnel  tests  LaRC  had  conducted  using  the  1.5%  model  (OV-101  configuration) 
were  used  in  developing  the  final  fairings  for  the  preflight  ADDB.  The  high  fidelity  OV-102  model 
data  was  still  considered  prime  and  weighed  the  heaviest  of  all  the  data.  The  LaRC  tests 
contributed  significantly  to  filling  in  gaps  of  the  OV-102  data  base  and  to  establishing  model-to- 
model  and  tunnel-to-tunnel  repeatability.  The  product  of  the  Panel  was  the  official  Space  Shuttle 
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Orbiter  ADDB  published  in  October  1978  and  revised  in  April  1979. 

Prior  to  the  formation  of  the  Panel,  the  technique  of  reviewing  the  "correctness"  of  the  ADDB 
published  by  the  prime  contractor  was  to  conduct  a formal  review  after  publication.  Unless  major 
discrepancies  were  identified  and  agreed  to,  no  changes  were  usually  made  as  a result  of  the  formal 
review.  Because  the  Panel  worked  closely  with  the  prime  contractor,  making  recommendations  and 
changes  during  the  development  of  the  ADDB,  a much  more  detailed  review  and  refinement  than  by 
previous  means  of  review  was  made  possible.  Almost  all  of  the  changes  recommended  by  the  Panel  were 
accepted  and  implemented  with  minimum  schedule  impact.  A significant  amount  of  work  by  individual 
members  was  published  directly  in  the  ADDB. 

After  the  Panel's  work  was  complete,  a minor  update  to  the  April  '79  ADDB  was  made  and  the 
official  aerodynamic  data  base  was  frozen  in  May  1980  to  conduct  final  GN&C  verification  for  STS-1  . 
This  data,  the  official  preflight  Orbiter  aerodynamic  data  base,  was  published  as  a NASA  Contractor 

Report  in  November  1980,^  and  was  designated  as  the  "STS-1  ADDB." 

In  January  1980,  while  conducting  an  in-house  research  test  on  high  angle  of  attack 
aerodynamics,  LaRC  found  a large  difference  in  directional  stability  at  Mach  6 from  what  the  STS-1 
ADDB  predicted.  This  gave  rise  to  some  potential  FCS  concerns  about  performing  a bank  reversal  in 
flight  near  Mach  6.  An  investigation  of  this  potential  problem  led  to  Part  3 of  the  verification 
test  phase:  Supersonic/hypersonic  lateral-direct ional  nonlinearity  tests. 

It  turned  out  that  the  lateral-directional  characteristics  are  highly  nonlinear  with  sideslip 
angle  (B)  at  certain  angles  of  attack.  Further,  this  phenomena  is  not  limited  to  Mach  6,  but  occurs 
over  a Mach  range  of  2 to  8,  at  various  a's.  Also,  nonlinearities  of  the  sideslip  derivatives  with 

Mach,  a,  and  speedbrake  were  identified  that  had  not  been  observed  previously.  The  basic  problem 

was  that  the  sideslip  derivatives  are  linear  only  over  a range  of  1/2°  beat  in  some  cases.  The 

smallest  tested  previously  was  1°  and  most  data  was  at  2°.  The  cause  of  these  nonlinearities  is 
thought  to  be  a complex  vortex  interaction  with  the  vertical  tail/speedbrake . 

Discovery  of  a problem  of  this  magnitude  so  late  in  the  Shuttle  program  development  (projected 
launch  date  of  STS-1  was  just  over  1 year  from  discovery  of  problem)  presented  a schedule  problem  of 
how  to  acquire  the  necessary  wind  tunnel  data,  analyze  the  results,  and  put  the  data  fairings  in  a 
form  that  was  acceptable  for  input  to  the  simulators  so  that  a safety  assessment  could  be  performed 
prior  to  the  STS-1. 

In  order  to  resolve  the  aerodynamic/FCS  anomaly  in  time  to  support  STS-1,  a team  was  formed 
consisting  of  JSC,  the  prime  contractor,  LaRC,  and  wind  tunnel  facility  engineers.  This  included 
aerodynamicist s,  flight  control  engineers,  and  simulation  engineers  at  JSC.  The  wind  tunnel  tests 
conducted  are  shown  under  Part  3 in  figure  19. 

Detailed  analysis  of  the  test  data  was  performed  on-site  during  each  wind  tunnel  test  such  that 

by  the  end  of  the  test,  final  fairings  were  complete  and  the  data  had  been  converted  into  a form 

ready  for  the  flight  simulators.  The  data  was  then  evaluated  on  an  engineering  simulator  at  JSC. 
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The  results  showed  that  the  large  nonlinearities  with  B could  cause  loss  of  control  during  a bank 
reversal  when  combined  with  certain  FCS  uncertainties  such  as  winds  and  errors.  As  a result,  the 
trajectory  of  the  first  flight  (STS-1)  was  changed  to  avoid  a bank  reversal  near  Mach  6. 


These  new  wind  tunnel  data  were  then  used  to  produce  a major  update  in  the  STS-1  ADDB, 
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published  in  April  1982  as  the  Pre-Operational  ADDB.  The  Pre-Operational  (Pre-Op)  ADDB,  although 
published  after  STS-1,  contains  no  flight  data  (except  for  limited  ALT  results)  and  represents  the 
true  best  estimate  of  preflight  aerodynamics  of  the  Space  Shuttle  Orbiter.  Ultimately,  the  Pre-Op 
ADDB  will  be  updated  based  on  orbital  flight  test  results  to  produce  the  Operational  Aerodynamic 
Data  Book  (OADB)  for  the  Orbiter.  This  will  be  the  aerodynamic  data  base  used  for  Shuttle 
operational  planning  such  as  mission  planning,  trajectory  design,  and  crew  training. 

WIND  TUNNEL  DATA  BASE  ANALYSIS 

It  was  a major  undertaking  just  to  collect  the  wind  tunnel  data  base.  The  fruits  of  this 
undertaking  would  be  meaningless  unless  the  results  of  these  tests  could  be  presented  to  the 
aerodynamic  analysts  in  a digestable  form.  The  Space  Shuttle  Program  management  turned  to  the 
computer  to  facilitate  this  analysis.  Chrysler  Corporation's  Space  Division  devised  and  operated  a 
system  of  computer  programs  called  "DATAMAN"  to  document  and  present  test  results  to  the  aerodynamic 
analysts  in  a variety  of  plotted  forms.  The  analyst  could  have  at  his  disposal  the  data  in  the 
desired  form  allowing  an  efficient  analysis  to  be  performed.  Chrysler  received  data  tapes  from  the 
various  facilities,  transformed  the  various  tapes  to  a common  format,  and  used  the  computer  program 
system  to  correlate,  document,  and  produce  data  upon  request  to  the  aerodynamic  analysts.  A 
detailed  review  of  this  unique  capability  is  presented  in  reference  16. 


ORBITER  AERODYNAMIC  CHARACTERISTICS 


Preflight  predicted  aerodynamic  characteristics  of  the  final  Orbiter  vehicle  are  summarized  in 
this  section.  These  characteristics  derived  from  an  extensive  wind  tunnel  test  data  base  adjusted 
for  those  effects  which  could  not  be  simulated  in  the  wind  tunnel.  Before  discussing  the 
corrections  made  to  this  data  base  and  the  actual  aerodynamic  characteristics,  the  management, 
control,  and  verification  of  the  aerodynamic  data  base  will  be  reviewed. 

The  challenge  of  the  management  of  the  aerodynamic  data  base  falls  into  two  areas:  1)  creating 
and  controlling  a common  data  base  for  the  multitude  of  users  within  NASA,  and  the  contractors 
across  the  nation;  and  2)  verifying  that  data  base.  Late  in  Phase  B,  a common  Orbiter  aerodynamic 
configuration  was  selected  as  a focus  for  all  in-house  and  contractor  efforts.  The  aerodynamics  for 
this  configuration  were  compiled  into  an  ADDB  to  be  used  for  all  computer  simulations.  The  use  of  a 
central  controlled  ADDB  continued  into  the  Phase  C & D time  period.  (An  ADDB  of  estimated 
aerodynamic  characteristics  for  the  ATP  configuration  was  submited  with  the  Rockwell  proposal.)  As 
the  configuration  evolved  a data  book  consisting  of  the  estimated  aerodynamic  characteristics  for 
each  configuration  was  produced  and  subsequently  verified  experimentally.  To  further  standardize 
the  data  base  the  process  of  centrally  digitizing  and  producing  computer  tapes  of  each  data  book  was 
initiated  early  in  Phase  C & D.  Thus,  the  aerodynamic  data  base  evolved  into  an  ADDB  and  its 
corresponding  digital  computer  tape,  under  configuration  control  of  one  of  the  major  program  panels. 

ADDB  verification  was  accomplished  by  a detailed  technical  review  by  NASA  experts  prior  to  each 
programmatic  milestone  until  approximately  1-year  before  the  first  manned  orbital  flight.  (The 
procedure  used  in  this  time  frame  was  addressed  previously  in  Phase  III  of  the  Wind  Tunnel  Section.) 


WIND  TUNNEL  DATA  BASE  ADJUSTMENTS 


The  traditional  free-stream  Reynolds  number  was  selected  for  the  flow  field  scaling  parameter 
below  Mach  15,  while  a viscous  interaction  parameter  (V^)  was  utilized  at  higher  Mach  numbers. 

Since  the  test  facilities  were  able  to  provide  near-flight  Reynolds  number  simulations  over  a large 
Mach  number  range,  as  shown  in  figure  18,  no  corrections  to  the  wind  tunnel  results  were  required. 
At  lower  Mach  numbers,  the  traditional  adjustments  were  applied  for  Reynolds  number  effect  on 
friction  drag.  Additional  adjustments  were  applied  to  the  profile  drag  to  account  for  the  added 
roughness  of  the  thermal  protection  system  tiles,  and  for  minor  protuberances,  which  could  not  be 
simulated  on  the  wind  tunnel  test  models. 


222 


In  general,  no  attempt  was  made  to  obtain  a wind  tunnel  measurement  of  the  effects  of 
structural  deformation  on  the  longitudinal  aerodynamics  through  testing  of  conventional  aeroelastic 

or  deformed  models.  Since  at  higher  q's  these  effects  can  be  significant,  some  adjustment  to  the 
wind  tunnel  data  must  be  made  to  provide  adequate  estimates  of  the  flight  aerodynamics.  The 
approach  used  in  the  Shuttle  Program  to  estimate  the  aeroelastic  effects  is  thought  to  be  unique. 

First,  a sensitivity  analysis  was  performed  with  the  aid  of  a structural/aerodynamic  analysis 
17  18 

computer  program.  * The  geometry  model  used  is  shown  in  figure  21.  This  program  was  used  to 
systematicly  stiffen  various  portions  of  the  vehicle  structure  to  analytically  evaluate  the  effect 
of  the  stiffness  changes  on  the  aerodynamics.  The  results  indicated  that  the  major  longitudinal 
aeroelastic  effects  were  produced  by  deformation  of  the  wing  back-up  structure  where  the  elevon 
actuator  is  attached,  resulting  in  a change  of  the  elevon  position  not  measured  by  the  vehicle 
position  sensors.  The  effect  was  modeled  by  combining  a rotary  spring  constant,  as  determined  from 
vehicle  loading  tests,  with  wind  tunnel  derived  aerodynamic  hinge  moment  characteristics  to 

determine  a correction  (usually  less  than  1°)  to  the  rigid  elevon  deflection  angle.  The  "elastic" 
elevon  angle  is  used  to  look-up  the  rigid  aerodynamic  characteristics  in  determining  the  vehicle 
longitudinal  aeroelastic  characteristics. 

The  computer  program  indicated  the  major  aerodynamic  effect  in  the  directional  axis  was  the 
deformation  of  the  vertical  tail  and  the  aft  fuselage.  Of  particular  concern  was  the  predicted  40% 
reduction  in  rudder  power  due  twisting  of  the  vertical  tail  around  its  elastic  axis.  It  was  felt 
that  this  large  effect  could  not  be  left  to  theoretical  prediction  techniques  alone.  After 
establishing  the  structural  characteristics  of  the  vertical  tail  and  aft  fuselage  from  the 
structural  test  article,  an  aeroelastical ly  scaled  vertical  tail  was  constructed  which  simulated  the 
root  spring  constant  and  tail  stiffness  distribution.  It  was  then  tested  on  a standard  force  model 

across  the  high  q Mach  range.  The  results  from  these  wind  tunnel  tests  were  then  analytically 
adjusted  to  "free"  the  orbiter  from  the  sting  mounting  constraint  necessary  in  the  wind  tunnel.  The 

adjusted  wind  tunnel  data  are  compared  with  the  computer  program  predictions  in  figure  22  for  a q of 
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300  psf  (14,364  N/m  ).  As  can  be  seen,  the  correction  is  significant.  A detailed  development  of 
this  unique  approach  for  evaluating  aeroelastic  effects  is  presented  in  reference  26. 

AERODYNAMIC  CHARACTERISTICS 

The  key  aerodynamic  parameters  which  have  a significant  influence  on  the  Orbiter  performance, 
and  stability  and  control  are  shown  in  table  3.  Lift,  drag,  and  pitching  moment  are  the  primary 
aerodynamic  parameters  governing  the  entry  trajectory  and  range  capability.  Pitching  moment 
determines  the  bodyflap  setting  required  for  trim.  Design  areas  sensitive  to  trim  setting  are 
elevon  and  bodyflap  heating  during  initial  entry,  and  control  surface  actuator  stall  limits  at 
transonic  speeds.  In  addition,  there  is  an  interaction  between  elevon  setting  and  lateral- 
directional  control  capability  because  of  the  change  of  aileron  effectiveness  with  elevon  position. 
Lateral-directional  trim  and  control  capability  is  governed  by  the  aileron,  rudder,  and  sideslip 
derivatives.  Above  Mach  3.5  the  aileron  is  used  for  both  roll  and  yaw  trim  before  the  rudder 
becomes  effective. 

In  the  spacecraft  mode  of  operation,  bank  maneuvers  are  initiated  by  the  yaw  jets  and  the 
aileron  is  used  to  coordinate  the  maneuver.  Between  Mach  3.5  and  1.5  the  flight  control  system 
gains  are  scheduled  to  provide  a transition  to  a conventional  aircraft  mode  where  the  bank  maneuvers 
are  initiated  by  the  ailerons  about  the  roll  axis  and  the  rudder  is  used  to  coordinate  the  maneuver. 
Both  the  aileron  and  rudder  are  used  for  trim  below  Mach  3.5.  The  derivatives  C , Crt  , C , Cn  , 
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C , C0  were  key  parameters  in  establishing  control  capability,  reaction  control  system 
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propellant  usage,  and  the  switch-over  point  from  spacecraft  to  aircraft  control  modes. 

HIGH  ALTITUDE  AERODYNAMICS 

Entry  interface  for  the  Shuttle  has  been  defined  as  400,000  ft  (120,000  meters)  altitude.  In 
this  high  altitude  region,  rarefied  gas  flows  are  encountered  by  the  Orbiter  as  it  enters  the 
atmosphere.  Aerodynamic  design  issues  in  this  region  involve  determining  the  effectiveness  of  the 
RCS  control  jets  and  their  influence  on  the  Orbiter  flow  field,  in  addition  to  defining  viscous 
interaction  effects  associated  with  low  Reynolds  number/high  Mach  number  flows. 
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Initial  entry  aerodynamic  characteristics  are  strongly  influenced  by  interactions  between  the 
RCS  jet  plumes  and  the  local  flow  field  over  the  Orbiter  (figure  15).  The  application  of  the  RCS 

- 2 2 

data  to  a typical  entry  flight  condition  of  q * 1.0  lb/ft  (47.9  N/m  ) at  an  altitude  of  260,000  ft 

(79,250  meters)  are  presented  in  figure  23  for  three  left  downfiring  RCS  jets.  The  RCS  impingement 
and  flow  interaction  results  have  an  adverse  effect  on  pitch  and  roll  control  while  increasing  yaw 
control . 

Viscous  interaction  primarily  affects  the  shear  forces  with  essentially  no  affect  on  normal 
force.  Variation  of  along  the  nominal  entry  trajectory  is  illustrated  in  figure  24.  High  values 

of  V;  correspond  to  low  values  of  Reynolds  number  which  is  associated  with  the  thickening  of  the 
hypersonic  laminar  boundary  layer  causing  increased  shear  on  the  lower  surface  of  the  Orbiter. 
Evidence  of  this  is  seen  in  figure  25  as  an  increase  in  axial  force  coefficient  with  increasing  V' 
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yields  no  change  in  normal  force.  There  is  insignificant  effect  of  on  pitching  moment  for  0° 

bodyflap  as  shown  at  the  top  of  figure  26.  At  negative  (trailing  edge-up)  bodyflap  deflections,  the 
movement  of  the  bodyflap  has  little  effect  on  the  boundary  layer  on  the  lower  surface  of  the 

Orbiter,  and  consequently,  the  effect  of  on  pitching  moment  is  similar  to  the  0°  deflection  case. 
However,  for  positive  (trailing  edge-down)  deflections,  the  bodyflap  control  effectiveness  decreases 
with  increasing  V^,  (figure  26).  At  large  values  of  V^,  the  correspondingly  low  Reynolds  number 

results  in  a thickening  of  the  boundary  layer  which  causes  the  separation  point  to  move  forward  with 
increasing  control  deflection.  This  causes  the  center  of  pressure  to  move  forward,  resulting  in 

reduced  pitching  moment  effectiveness  with  increasing  V'.  Effects  of  V'  on  aerodynamic  performance 
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characteristics  are  indicated  in  figures  27  and  28  for  a nominal  entry  trajectory.  The  decrease  in 
L/D  ratio  caused  by  the  increase  in  axial  force  is  accounted  for  in  design  of  the  entry  trajectory. 

LONGITUDINAL  CHARACTERISTICS 

Longitudinal  stability  and  control  characteristics  for  low  speed  to  hypersonic  Mach  numbers  are 
illustrated  in  figures  29  and  30.  These  data  are  based  on  an  extensive  series  of  wind  tunnel  tests. 
Representative  wind  tunnel  data  are  shown  on  the  curves.  The  low-speed  longitudinal  characteristics 
shown  in  figure  29  demonstrate  stall-free  characteristics  over  operating  flight  conditions.  The 
predicted  characteristics  are  compared  with  test  data  obtained  with  a 0.36-scale  model  in  the  ARC 
40x80-ft  (12.19x24.38  m)  wind  tunnel.  The  changes  in  low-speed  stability  shown  by  the  large  changes 
in  pitching  moment  at  high  a's  are  due  to  leeside  separation  on  the  Orbiter  wing  induced  by 
vortices  from  the  wing/fuselage  junction.  The  leeside  flow  separation  influences  the  supersonic 
stability  characteristics  also.  It  can  be  seen  in  figure  30  that  for  Mach  10  and  5,  the  variation 
of  pitching  moment  with  normal  force  coefficient  for  zero  and  positive  elevon  deflection  follows  the 
typical  hypersonic  pitch  characteristics.  This  relationship  between  pitching  moment  and  normal 
force  coefficient  does  not  follow  the  ’’sine  square"  variation  for  negative  elevon  deflections.  The 
change  in  characteristics  is  due  to  the  change  in  flow  pattern  on  the  leeside  of  the  Orbiter  wing  as 
influenced  by  negative  elevon  deflections. 

The  surface  flow  patterns  on  the  leeside  of  the  Orbiter  wing  at  supersonic  speeds  consist  of 
three  distinct  flows.  At  low  a's,  the  flow,  which  is  initially  perpendicular  to  the  leading  edge, 
is  turned  parallel  to  the  free-stream  by  the  presence  of  the  fuselage  (figure  31a).  When  the  angle 
of  attack  is  great  enough  to  cause  the  wing  leading  edge  shock  to  detach,  the  trailing  edge  shock 
will  become  strong  enough  to  separate  the  boundary  layer  (figure  31b).  This  separation  is  the 
result  of  subsonic  flow  aft  of  the  detached  shock  expanding  around  the  leading  edge  and  reattaching 
at  supersonic  speeds.  The  flow  must  still  be  turned  into  the  free-stream  direction  as  before.  The 
turning  is  accomplished  by  a strong  shock  that  causes  the  boundary  layer  to  separate.  The  wake 
begins  to  affect  the  flow  pattern  at  high  angle  of  attack  causing  a secondary  type  of  separation 
(figure  31c).  Leeside  flow  boundaries  at  Mach  6.0  are  shown  in  figure  32.  The  relationship  between 
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spanwise  location  of  the  shock  induced  separation,  — , and  Mach  number  was  obtained  from  a 
correlation  of  delta  wing  data.  The  shock  detached  boundary  was  obtained  from  oil  flow  photographs. 

The  effect  of  leeside  separation  on  wing  pitching  moment  is  shown  in  figure  33.  The  subsonic 
leading  edge  suction  that  occurs  when  the  bow  shock  detaches  results  in  a more  stable  pitching 
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moment  slope.  The  change  to  a more  stable  slope  is  the  result  of  leading  edge  suction  when  the  wing 
bow  wave  detaches  and  a reduction  of  lift  over  the  wing  area  aft  of  separation  line.  The  center  of 
pressure  is  more  aft  for  the  lift  gain  (due  to  leading  edge  suction)  than  for  the  lift  loss  due  to 
shock-induced  pressure  aft  of  the  separation  line.  The  wing  pitching  moment  becomes  more  stable, 

thus  accounting  for  the  increased  stability  shown  in  figure  30  for  +10°  elevon  deflection. 

Elevon  effectiveness  is  also  influenced  by  leeside  separation.  Loss  in  elevon  effectiveness  at 
high  negative  (trailing  edge  up)  deflection  can  be  attributed  to  the  effect  of  back-pressure  on  the 
leeside  flow  field.  Flap  type  controls  will  often  cause  boundary  layer  separation,  especially  in 
hypersonic  low-density  flows.  Such  back-pressure  effects  are  of  practical  concern  since  it  is 
desirable  to  control  the  Orbiter  with  leeward  control  deflection  (trailing  edge  up)  in  order  to 
minimize  control  surface  heating.  Figure  34  shows  elevon  effectiveness  data  obtained  from  the  AEDC 

tunnel  A at  Mach  5 for  an  elevon  deflection  of  -33°.  The  measured  elevon  effectiveness  is  seen  to 
be  less  than  shown  by  shock  expansion  theory.  This  is  probably  due  to  shock- induced  separation. 
The  extent  of  separation  increases  with  a.  After  the  a for  shock  detachment  is  reached,  the  back- 
pressure effect  from  the  elevon  will  affect  the  wing  flow.  At  high  a's,  the  positive  lift  produced 
by  the  wing  vortices  outweighs  the  negative  lift  generated  by  the  e levon-induced  flow  separation 
over  the  inner  wing  surface.  The  result  is  a loss  of  elevon  effectiveness  below  the  shock  expansion 
value.  Adjusting  the  theory  for  leeside  separation  results  in  reasonable  agreement  between  theory 
and  experiment. 

Static  trim  capability  for  the  elevon  and  bodyflap  mentioned  for  trim  to  the  forward  and  aft  eg 
positions  is  shown  in  figure  35.  The  control  schedules  presented  on  the  figure  are  for  determining 
maximum  obtainable  eg  trim  limits.  A reserve  for  maneuvering,  trimming  Ycg  offset,  manufacturing 
misalignments,  and  aerodynamic  uncertainties  has  been  added  to  the  limits  of  the  elevon 
effectiveness  data  to  establish  the  limits  shown  on  the  figure.  The  aft  eg  limits  are  based  on  a 

positive  elevon  deflection  of  15°  for  Mach  numbers  less  than  or  equal  to  10.  A positive  elevon 

deflection  of  10°  was  used  for  Mach  numbers  greater  than  10  due  to  thermal  protection  system  design 
limits  during  maximum  heating  conditions.  Forward  eg  trim  limits  are  based  on  an  incremental 
pitching  moment  coefficient  reserve  of  0.015  for  Mach  numbers  less  than  or  equal  to  10  and  0.02  for 
Mach  numbers  greater  than  10.  Figure  35  indicates  a slightly  reduced  forward  eg  trim  margin  at  Mach 

5.0  in  the  ot  range  from  20°  to  45°.  This  is  attributed  to  the  loss  in  elevon  effectiveness  due  to 
leeside  separation.  Center  of  gravity  trim  limits  for  the  entry  a schedule  are  shown  in  figure  36. 
Both  figures  35  and  36  indicate  that  a wide  trim  margin  exists  across  the  Mach  number  range. 

Elevon  control  power,  in  conjunction  with  the  bodyflap  and  speedbrake,  provide  trim  capability 
between  the  design  eg  limits.  The  elevon  schedule,  shown  in  figure  37,  illustrates  the  nominal  and 
the  most  positive  and  negative  settings  for  trim  at  forward  and  aft  eg  positions.  The  extreme 
settings  account  for  control  margin  and  uncertainties  in  aerodynamic  characteristics. 

LATERAL  DIRECTIONAL  CHARACTERISTICS 


Lateral-directional  stability  and  control  characteristics  for  a mid  eg  along  the  nominal  entry 
trajectory  are  illustrated  in  figures  38,  39,  and  40.  The  Orbiter  exhibits  a stable  dihedral  effect 
(negative  C ) across  the  complete  Mach  range  during  both  the  spacecraft  and  aircraft  control  modes 
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(figure  38).  During  the  spacecraft  mode,  and  during  transtion  to  the  aircraft  mode,  the  vehicle  is 
directionally  unstable.  C becomes  positive  indicating  static  stability  in  yaw  between  Mach  2 and 
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1,  and  remains  directionally  stable  throughout  the  aircraft  mode  (Mach  numbers  below  approximately 
1.5).  Aileron  and  rudder  control  effectiveness  characteristics  are  illustrated  in  figures  39  and 


40. 


Early  analytical  studies  predicted  an  effect  of  elevon  deflection  on  the  lateral-directional 
characteristics.  Studies  showed  that  the  relatively  large  sized  elevon  in  the  presence  of  the  deep, 
flat-sided  fuselage  could  induce  a change  in  the  pressure  distribution  in  the  aft  region  of  the 
fuselage.  The  change  in  the  pressure  distribution  resulted  in  an  incremental  change  in  side  force, 
yaw,  and  rolling  moment  when  the  vehicle  was  yawed.  The  effect  of  elevon  on  lateral-directional 
stability  is  illustrated  in  figures  41  and  42.  The  aileron  control  derivatives  C0  and  C are 


also  affected  by  elevon  position  as  shown  in  figures  43  and  44. 
derivatives  to  elevon  position  influences  vehicle  control  boundaries. 


The 
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Low-speed  directional  stability  characteristics  exhibit  a strong  combined  Reynolds  number  and 
a effect  as  shown  in  figure  45.  The  figure  illustrates  the  importance  of  full-scale  Reynolds  number 
testing  on  high  a aerodynamics.  Test  data  obtained  from  models  tested  at  low  Reynolds  number  (below 

5 x 10^  based  on  MAC)  show  essentially  no  change  of  directional  stability  with  a.  The  early  work  of 
19  20 

Polhamus  and  Jorgensen  and  Brownson  indicated  that  Reynolds  number  and  body  corner  radius  could 
have  a significant  effect  on  the  high  a characteristics  of  the  Orbiter.  These  predictions  were 
borne  out  when  the  Orbiter  model  was  tested  at  near  full-scale  Reynolds  number  in  the  ARC  40x80-foot 
(12.2x24.4  m)  wind  tunnel.  It  can  be  seen  in  figure  45  that  the  high  Reynolds  number  test  data  show 
a decrease  in  directional  stability  with  angle  of  attack  which  is  in  contrast  to  the  low  Reynolds 
number  data  which  show  essentially  no  change  in  stability  with  a. 


AERODYNAMIC  UNCERTAINTIES 


The  two  program  management  decisions  given  in  the  Background  section  (to  freeze  the  Orbiter 
systems  configuration  at  ATP  and  to  fly  a manual  Orbital  flight  on  the  initial  mission)  had  a 
significant  influence  on  the  approach  selected  for  the  aerodynamic  design  and  verification  of  the 
Orbiter,  particularly  with  regard  to  aerodynamic  uncertainties.  These  decisions  led  to  the 
development  of  two  types  of  aerodynamic  uncertainties:  (1)  Wind  tunnel  uncertainties,  and  (2)  Wind 
tunnel-to-f light  uncertainties. 


WIND  TUNNEL  UNCERTAINTIES 

The  first  decision  baselined  both  the  FCS  and  the  aerodynamic  configuration  (as  well  as  other 
systems  and  subsystems)  in  August  1972  at  the  ATP  milestone.  Thereafter,  the  only  aerodynamic  and 
FCS  changes  that  were  permitted  were  those  which  were  required  to  fix  critical  system  design 
problems.  As  evaluations  of  the  baseline  systems  were  conducted,  it  became  clear  that  some 
significant  changes  to  both  the  FCS  and  aerodynamic  design  would  be  required.  This  resulted  in  the 
final  FCS  and  the  aerodynamic  design  being  conducted  in  parallel.  This  presented  a problem  of  how 
to  design  a FCS  "tuned"  to  the  vehicle  aerodynamics  while  the  baseline  aerodynamic  data  base  was 
still  evolving.  Somehow,  the  FCS  had  to  be  designed  to  be  insensitive  to  "reasonable"  changes  in 
the  aerodynamic  characteristics.  This  led  to  the  requirement  for  a set  of  aerodynamic  "design-to" 
uncertainties  that  would  be  used  along  with  the  baseline  nominal  aerodynamics  in  FCS  design.  These 
"design-to"  uncertainties,  designated  "tolerances",  were  defined  as  the  minimum  error  that  is 
expected  in  the  preflight  aerodynamic  predictions. 

With  the  wind  tunnel  data  base  as  the  foundation  for  the  preflight  predictions,  it  was  assumed 
that  the  minimum  error  that  could  be  expected  would  be  the  ability  to  reproduce  experimental  results 
between  various  wind  tunnel  tests.  Therefore,  repeat  tests  were  performed  using  various  wind  tunnel 
facilities,  different  models,  and  on  occasion,  different  test  organizations.  Although  the 
individual  causes  for  any  differences  were  not  specifically  identified,  it  is  felt  the  total 
difference  is  representative  of  what  may  be  expected  for  wind  tunnel  test  repeatability. 

As  an  illustration  of  the  mechanics  of  this  procedure,  consider  pitching  moment  coefficient, 
where  repeat  tests  are  presented  along  with  ADDB  estimates  in  figure  46.  It  can  be  seen  from  this 
figure  that  a 0.05  scale  model  (model  39-0)  was  tested  in  both  ARC  11x11  foot  facility,  and  in  the 
LaRC  16-foot  transonic  facility.  Similarly,  a 0.015  scale  model,  model  44-0,  was  tested  by  LaRC  in 
three  facilities:  1)  the  Ling-Temco-Vought  High  Speed  Wind  Tunnel  (LTV  4x4);  2)  the  LaRC  8-foot 
tunnel;  and  3)  the  ARC  11x11  foot  facility.  In  addition,  the  0.02  scale  model,  model  105-0  was 
tested  in  the  LaRC  16T  tunnel.  With  all  these  potential  sources  of  differences,  a peak-to-peak 
repeatability  in  pitching  moment  coefficient  (C^)  of  approximately  0.006  was  observed.  This 

repeatability  represents  the  combined  error  sources  of  the  following:  1)  the  same  model  in  several 
tunnels  (tunnel-to-tunnel  repeatability);  2)  different  models  in  the  same  tunnel  (model-to-model 
repeatability);  and  3)  different  test  organizations  (testing  technique  differences). 

Based  on  this  correlation,  the  difference  between  the  wind  tunnel  results  and  the  ADDB  at 
various  angles  of  attack  were  correlated  with  Mach  number  (figure  47).  Tolerances  (wind  tunnel 
uncertainties)  were  obtained  by  fairing  a curve  through  these  data  points  using  engineering 
judgement.  The  nominal  flight  angle  of  attack  was  given  a high  weighting  in  the  fairing  process.  A 
similar  process  was  used  to  develop  tolerances  for  lift  and  drag  coefficients,  the  sideslip 
derivatives,  aileron  derivatives,  and  rudder  derivatives.  Reference  21  provides  a more  detailed 
report  on  the  development  of  the  Orbiter  wind  tunnel  uncertainties. 
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WIND  TUNNEL-TO-FLIGHT  UNCERTAINTIES 


The  second  program  management  decision,  to  fly  a manned  vehicle  on  the  initial  orbital  flight 
test  of  the  Space  Shuttle,  raised  the  question  of  how  to  maximize  mission  safety  without  the  benefit 
of  conducting  a graduated  flight  test  program  as  is  traditionally  done  in  most  aircraft  development 
programs.  This  decision  led  to  the  requirement  to  provide  a reasonable  estimate  of  the  maximum 
possible  errors  in  the  preflight  aerodynamic  predictions  that  might  occur  on  the  first  Space  Shuttle 
flight.  These  aerodynamic  uncertainties  were  designated  "variations'*. 

In  order  to  certify  that  the  Space  Shuttle  system  was  ready  for  the  first  flight,  a multitude 
of  flight  simulations  were  conducted  using  the  aerodynamic  variations,  along  with  other  system 
uncertainties,  to  "stress"  test  the  FCS . Based  on  the  results  of  these  simulations,  a eg,  elevon 
schedule,  and  the  FCS  gains  were  selected  for  STS-1  which  maximized  the  stability  and  control 
margins,  thereby  maximizing  mission  safety. 

However,  these  "worst  case"  uncertainties  must  not  be  so  conservative  as  to  completely 
invalidate  the  FCS  design.  Since  the  preflight  predictions  were  primarily  based  on  wind  tunnel 
tests,  variations  would  represent  the  possible  errors  between  wind  tunnel  and  flight  aerodynamics. 
It  was  felt  that  the  most  reasonable  approach  for  the  development  of  variations  would  be  to  analyze 
the  wind  tunnel  to  flight  test  differences  of  previous  aircraft  programs.  Unfortunately,  the 
verification  of  preflight  predicted  aerodynamics  was  not  a major  objective  of  most  of  the  earlier 
flight  test  programs.  This  severely  limited  the  amount  of  data  available  for  conducting  flight  test 
to  wind  tunnel  comparisons.  The  flight  data  base  was  further  limited  by  restricting  the  comparison 
to  those  vehicles  which  were  geometrically  similar  to  the  Orbiter. 

Variations  were  established  by  fairing  the  differences  between  the  flight  and  predicted 
aerodynamics  as  a function  of  Mach  number.  Because  the  selections  of  the  configurations  and  the 
fairing  process  are  very  subjective  in  nature,  a team  of  aerodynamicist s from  NASA  Dryden  Flight 
Research  Center,  NASA  Johnson  Space  Center,  Air  Force  Flight  Test  Center,  and  the  prime  contractor 
was  formed  to  conduct  the  analysis  and  reach  a consensus  on  variations. 

The  team's  flight-to-predicted  pitching  moment  correlation  and  their  recommended  variation 
fairings  are  presented  as  a function  of  Mach  number  in  figure  48.  As  can  be  seen  from  this  figure, 
the  flight  data  is  limited  to  below  Mach  3.  In  Mach  regimes  where  flight  data  was  unavailable  and 
the  ideal  gas  assumption  was  justified,  variations  were  obtained  by  multiplying  the  wind  tunnel- 
derived  tolerances  by  a safety  factor,  usually  1.5.  A similar  process  was  used  to  develop 
variations  for  the  other  aerodynamic  parameters.  A more  detailed  development  of  variations  is  given 
in  reference  22. 


A detailed  investigation  of  the  effect  of  real  gas  effects  was  conducted  in  1974  using  state 
of  the  art  theoretical  techniques.  Geometric  limitation  of  the  computer  codes  at  that  time  did  not 
lend  sufficient  confidence  to  use  these  results  in  adjusting  the  ideal  gas  wind  tunnel  data. 
Instead,  a conservative  estimate  of  the  real  gas  effect  was  added  to  the  pitching  moment  tolerances 
to  estimate  variation  in  the  high  altitude  flight  region.  Presented  in  figure  49  is  pitching  moment 
variation  as  a function  of  the  viscous  interaction  parameter  in  this  flight  region.  The  predicted 
real  gas  effects  gave  a more  nose  moment  up  to  the  basic  vehicle  pitching  moment  than  ideal  gas 
predictions.  Therefore,  the  real  gas  increments  were  added  to  the  positive  pitching  moment 
tolerances  resulting  in  the  unsymmetr ical  variations  illustrated  in  this  figure.  A procedure  for 
statistically  combining  these  uncertainties  is  delineated  in  reference  23. 

It  is  believed  that  the  Space  Shuttle  Orbiter  is  the  first  winged  aircraft /spacecraft  to  be 
designed  using  a systematic  development  and  application  of  aerodynamic  uncertainties. 


THE  ACCOMPLISHMENTS 


The  success  of  the  first  orbital  flight  of  the  Space  Shuttle  in  April  1981  demonstrated  the 
successful  aerodynamic  design  and  development  of  a vehicle  configuration  capable  of  flying  both  as  a 
spacecraft  and  as  an  aircraft,  and  that  the  preflight  predictions  were  of  sufficient  accuracy  for  a 
safe , manned  re-entry.  The  question  now  becomes  how  well  did  the  aerodynamicist  do  in  the 

. . 12 

predictions?  These  preflight  aerodynamic  predictions  represent  the  culmination  of  the  most 
intense  aerodynamic  development  effort  ever  undertaken.  The  foundation  of  these  predictions  was  an 
extensive  wind  tunnel  program  of  more  than  27  ,000  occupancy  hours.  This  wind  tunnel  data  base  has 
been  extensively  analyzed  by  a team  of  aerodynamicist 8 representing  expertise  from  NASA,  the  prime 
contractor,  and  the  Department  of  Defense.  State  of  the  art  computer  codes  supplemented  the  wind 
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tunnel  analysis.  The  success  in  predicting  the  flight  aerodynamics  represented  a test  of  the 
nation's  state  of  the  art  aerodynamic  capability  in  the  1970's.  For  the  first  time  in  aircraft 
development  history,  the  aerodynamicist  was  required  to  establish  uncertainty  levels  (bounds)  for 
preflight  predictions.  An  assessment  of  how  well  the  aerodynamic  community  performed  is  indicated 
by  the  ability  to  predict  flight  data  within  the  wind-tunnel-t o-f light-uncertainties  (i.e. 
variations) . 


CORRELATION  OF  FLIGHT  WITH  PREDICTED 
FLIGHT  TEST  PROGRAM 

One  of  the  major  objectives  of  the  Orbiter  flight  test  program  is  the  accurate  determination  of 
the  aerodynamic  characteristics  where  placards  in  the  operational  flight  envelope  have  been 
identified  due  to  possible  uncertainties  (variations)  in  the  aerodynamics.  For  the  first  orbital 
flight  (STS-1),  flight  test  maneuvers  were  not  conducted  in  order  to  minimize  safety  risks.  During 
the  second  and  subsequent  flights,  specially  designed  flight  test  maneuvers  were  conducted  to  permit 
aerodynamic  data  extraction. 

Since  during  entry  the  Orbiter  is  in  gliding  flight  with  a relatively  steep  glide  path  slope, 
correlation  of  Orbiter  flight  data  with  predicted  was  somewhat  more  difficult  than  with  more 
conventional  powered  aircraft.  The  aerodynamic  analyst  was  faced  with  the  dilemma  of  having  all 
flight  conditions  varying  simultaneously  from  entry  to  touchdown.  Accordingly,  the  correlation  of 
cause  and  effect  was  considerably  more  difficult. 

Although  a number  of  parameters  have  a significant  effect  on  the  aerodynamics,  Mach  number  was 
selected  as  the  prime  correlating  parameter  in  order  to  provide  an  overview  of  the  entire  flight. 
Therefore,  an  analysis  technique  must  be  selected  to  minimize  the  effect  of  the  other  parameters. 

In  order  to  make  a meaningful  correlation  of  data  from  several  flights,  the  effect  of  flight- 
to-f light  differences  in  the  independent  variables  needed  to  be  minimized.  Since  the  same  basic 

trajectories  were  flown  for  STS-1  thru  -4,  V^,  and  speedbrake  setting  (6gg)  vary  only  slightly 

(for  a given  Mach  number)  from  flight-to-f  light . The  most  significant  independent  variable  was 
elevon  position  (6g)  , which  was  progressively  more  positive  (trailing  edge  down)  on  each  successive 

flight.  The  elevon  position  varied  from  -3.5°  on  STS-2  to  5.8°  on  STS-4. 

In  order  to  correlate  data  over  several  flights,  the  flight  minus  predicted  was  correlated  with 
Mach  number.  The  predicted  variations  (uncertainties)  are  shown  to  gage  the  significance  of  any 
differences . 


LONGITUDINAL  PERFORMANCE  FLIGHT  RESULTS 

In  wind  tunnel  testing,  the  independent  parameters  are  known  precisely,  while  the  accuracy  of 
the  aerodynamics  is  not  so  well  known.  In  full  scale  flight  testing  the  aerodynamics  are,  by 
definition,  fully  simulated  and  the  aerodynamic  forces  and  moments  may  be  extracted  without  accurate 
knowledge  of  the  flight  conditions.  For  the  Orbiter,  determination  of  the  flight  independent 

variables  particularly  q,  with  sufficient  accuracy  for  aerodynamic  correlations  is  very  difficult. 
Significant  correlation  errors  can  occur  when  using  the  independent  variables  to  non-dimensional ize 
the  flight  forces  and  moments  and  to  "look-up"  the  corresponding  predicted  aerodynamic  coefficients. 
Therefore,  in  correlation  of  flight  results  with  predictions,  analysis  techniques  must  be  selected 
to  minimize  the  effect  of  possible  errors  in  the  independent  variables. 

L/D  was  selected  for  comparisons  of  predicted  and  flight  aerodynamics  since  it  is  only 
sensitive  to  errors  in  flight  accelerations  and  is  independent  of  dynamic  pressure.  As  seen  in 
figure  50,  flight  results  show  the  predicted  L/D  to  be  within  variations  down  to  near  Mach  1. 
Subsonic  L/D  was  underpredicted  by  approximately  5-10%. 


The  longitudinal  aerodynamic  center  of  pressure  (X^/Lg),  which  is  also  independent  of  q,  was 

selected  for  trim  comparisons.  For  a trimmed  vehicle,  the  longitudinal  center  of  pressure  coincides 
with  the  flight  eg.  Figure  51  presents  a comparison  of  the  flight  and  predicted  centers  of 
pressure.  As  can  be  seen  in  this  figure  at  Mach  numbers  above  10,  the  predicted  X / L is  more  aft 

* Cp  O 

than  the  flight  value  by  as  much  as  0.7%  of  the  reference  body  length  (1.9%  of  the  MAC),  which  is 
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well  outside  variations.  As  shown  from  Mach  3 to  10,  flight  results  indicate  that  longitudinal  trim 

was  accurately  predicted  even  though  unusually  high  ofs  between  15°  and  30°  were  flown.  Although 
the  flight  results  agreed  with  the  predicted  data  within  the  variation  (uncertainty)  bounds,  the 
agreement  is  less  than  satisfactory. 

LATERAL-DIRECTIONAL  STABILITY  AND  CONTROL  CORRELATIONS 

In  order  to  permit  the  accurate  extraction  of  stability  and  control  characteristics,  specially 
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designed  maneuvers  were  designed  and  conducted  starting  with  STS-2.  The  two  primary  types  of 
stability  and  control  maneuvers  are:  (1)  Programmed  Test  Inputs  (PTI)  and  (2)  Aero  Stick  Inputs 
(ASI).  Although  both  types  of  maneuvers  are  designed  preflight  to  yield  the  optimum  vehicle  motion 
for  data  extraction,  the  PTIs  generally  result  in  better  quality  data  because  they  are  precisely 
executed,  as  designed,  by  the  on-board  computer.  The  ASIs  are  manually  executed  by  the  crew.  More 
detailed  descriptions  of  the  flight  test  maneuvers,  instrumentation,  and  data  extraction  techniques 
may  be  found  in  references  24  through  27. 

Correlations  of  flight  with  predicted  data  are  shown  in  figures  52  through  55  for  lateral- 
directional  stability,  aileron  effectiveness,  and  rudder  effectiveness.  Over  the  majority  of  the 
entry  flight  regime,  flight  results  show  good  agreement  with  predicted  data.  However,  at  a few 
points  during  entry,  both  the  lateral-directional  stability  and  aileron  effectiveness  show 
differences  between  flight  and  predicted  data  approaching  the  variations  level.  Based  on  results 
extracted  from  the  PTIs,  rudder  effectiveness  appears  to  be  well  predicted  throughout  the  flight 
regime. 

As  might  be  expected,  the  two  regimes  which  show  the  largest  differences  between  flight  and 
predicted  data  are  the  transonic  and  hypersonic  real  gas  regimes.  The  transonic  wind  tunnels  have 
an  inherent  problem  area  of  blockage  and  shock  reflection  due  to  tunnel  walls,  while  at  the  same 
time  having  an  order  of  magnitude  lower  Reynolds  number  than  flight.  And  no  tunnel  today  has  the 
capability  to  truly  simulate  the  real  gas  environment.  In  the  hypersonic  regime  above  Mach  10,  the 
lateral  stability,  C , appears  to  be  less  stable  than  was  predicted  while  the  directional 
*6 

stability,  C , does  not  show  any  discernable  trends.  Flight  results  shown  in  figure  54  indicate 
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that  the  elevon  has  a stronger  effect  on  aileron  effectiveness  than  was  predicted. 

In  the  transonic  speed  regime,  the  vehicle  appears  to  be  laterally  more  stable  than  predicted. 
However,  there  is  considerable  scatter  in  the  flight  directional  stability  data.  Below  Mach  3,  the 
flight  results  indicate  that  the  aileron  is  less  effective  in  roll  than  predicted. 

Recalling  that  the  aerodynamic  variations  were  derived  from  wind  tunnel-t o-f 1 ight  differences 
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experienced  by  previous  aircraft,  it  appears  that,  based  on  four  flights,  the  Space  Shuttle 
Orbiter  stability  and  control  aerodynamics  were  generally  better  predicted  than  most  other  aircraft. 

RCS  JET  INTERACTION 

The  interference  between  the  RCS  jet  plumes  and  the  flow  field  at  high  altitudes  is  one  of  the 
more  significant  differences  observed  between  flight  and  predicted  data.  The  term  "jet 
interference"  is  used  to  indicate  combined  jet  interaction  and  plume  impingement  effects.  During 
the  first  flight  of  the  Space  Shuttle  (STS-1),  the  execution  of  the  first  bank  maneuver  during  entry 
resulted  in  damped  oscillations  in  sideslip  angle  and  roll  rate  that  were  significantly  larger  than 

were  predicted  by  preflight  simulations.  As  shown  in  figure  56,  oscillations  up  to  4°  in  sideslip 

occurred  in  flight  whereas  only  1°  was  predicted.  Analysis  of  flight  data  indicates  this  was  due  to 
an  overprediction  of  the  rolling  moment  due  to  side-firing  jets  (RM  ) in  the  high  Mach  number, 
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high  altitude  regime.  As  shown  in  figure  57,  flight  results  obtained  from  PTIs  conducted  on  STS-2, 
-3,  and  -4  not  only  confirm  this  overprediction,  but  also  indicate  that  the  jet  interference  is  a 
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function  of  the  number  of  jets  firing.  Because  the  RM  is  of  opposite  sign  and  greater  than 

JiSFJ 

the  rolling  moment  due  to  direct  thrust,  it  causes  a reversal  in  the  total  rolling  moment  due  a jet 
firing. 

Flight  results  have  also  shown  that  the  yawing  moment  jet  interference  (YM  ) and  side  force 

SFJ 

jet  interference  (SF  ) due  a side-firing  jet  were  underpredicted.  Analysis  of  flight  results 
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have  also  indicated  that  the  pitching  moment  (PM  ) and  rolling  moment  (RM  ) jet  interference 

JIDFJ  JIDFJ 

due  to  down-firing  jets  is  less  than  predicted,  as  shown  in  figure  58.  (A  more  comprehensive 
analysis  may  be  found  in  reference  28.) 

The  flight  test  results  obtained  to-date  indicate  that  both  the  side-firing  jets  and  the  down- 
firing jets  are  in  general  more  effective  than  predicted. 


POSTFLIGHT  ANALYSIS 
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Several  papers  at  the  Langley  "Shuttle  Performance:  Lessons  Learned"  conference  held  in 
March  of  1983,  addressed  the  aerodynamic  prediction  deficiencies  identified  in  a previous  section. 

An  analysis  is  presented  in  reference  30  concludes  that  the  underprediction  of  the  subsonic  L/D 
was  due  primarily  to  the  over-prediction  of  profile  drag.  An  over-estimate  of  the  drag  increment 
added  for  nonsimulation  of  the  thermal  protection  system  (TPS)  steps  and  gaps  led  to  this  profiLe 
prediction  deficiency. 

Reference  30  presents  an  analysis  of  the  longitudinal  trim  characteristics.  The  hypersonic 
pitching  moment  prediction  deficiency  is  attributed  to  an  error  in  prediction  of  the  center  of 
pressure.  This  is  further  substantiated  by  the  good  agreement  between  flight  and  predicted 
bodyflap  and  elevon  effectiveness. 

A possible  explanation  of  the  basic  vehicle  center  of  pressure  prediction  deficiency  is 
addressed  in  reference  31.  In  this  analysis,  Mach,  real  gas,  and  viscous  effects  are  incremented  to 
Mach  8 wind  tunnel  data.  Mach  and  real  gas  increments  were  obtained  from  computational  fluid 
dynamic  codes  that  were  not  available  in  the  Shuttle  development  time  frame.  An  estimate  of 
pitching  moment  increments  due  to  an  increase  in  viscous  shear  acting  on  the  bottom  surface  of  the 
vehicle  is  obtained  by  semi-empirical  means.  This  buildup  process  is  presented  in  figure  59. 
Figure  60  shows  a good  prediction  of  trim  bodyflap  when  these  corrections  are  applied. 

Finally,  reference  32  concludes  that  the  proper  wind  tunnel  simulation  parameter  for  RCS  jet 
interaction  still  has  not  been  identified. 


CONCLUDING  REMARKS 


This  paper  has  reviewed  the  aerodynamicist s'  success  in  conquering  the  challenges  that  were 
present  in  the  Space  Shuttle  Program. 

Apparently,  the  current  state  of  the  art  real  gas  prediction  techniques  would  properly  account 
for  the  hypersonic  center  of  pressure  change  encountered  during  re-entry  of  the  Space  Shuttle, 
although  the  quest  for  the  proper  RCS  wind  tunnel  simulation  parameter  continues. 

Although  the  flight  tests  for  the  majority  of  the  Shuttle  systems  are  completed,  the 
aerodynamic  flight  test  program  is  scheduled  to  continue  through  flight  17  in  order  to  certify 
flight  over  the  design  eg  range  of  0.65  Lfi  to  0.675  Lfi.  This  extended  program  will  allow  the 

program  not  only  to  refine  the  ability  to  predict  the  aerodynamics  of  the  Orbiter,  but  also  to 
provide  the  researcher  with  an  extensive  flight  data  base  which  should  be  used  to  improve  future 
testing  and  prediction  techniques. 

The  challenge  of  the  future  rests  in  the  hands  of  the  researcher  and  the  future  program 
analysts.  That  challenge  is  to  fully  exploit  the  methods,  the  information,  and  the  experience 
gained  from  the  most  extensive,  complicated,  aerodynamic  development  program  ever  accomplished: 
America's  Space  Shuttle. 
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TABLE  1.-  AERODYNAMIC  DESIGN  CRITERIA 


PARAMETER 

VALUE 

ANGLE  OF  ATTACK 

HYPERSONIC 

25  TO  50  DEG 

TRANSONIC 

OTO  15  DEG 

SUBSONIC 

-5  TO  20  DEG 

CENTER-OF-GRAVITY  RANGE 

MINIMUM  TRAVEL 

2%  BODY  LENGTH 

DESIGN  RANGE 

0.65  Lb  — 0.675  Lb 

LANDING  PERFORMANCE 

PAYLOAD 

(14,515  Kg)  32,000  LB 

LANDING  WEIGHT  (WITH  PAYLOAD) 

(85,230  Kg)  187,900  LB 

MINIMUM  DESIGN  TOUCHDOWN  SPEED,  VD 

(88  m/3)  171  KNOTS 

LONGITUDINAL  STABILITY 

MINIMUM  HYPERSONIC  STATIC  MARGIN 

POSITIVE 

MINIMUM  SUBSONIC  STATIC  MARGIN 

(AFT  CENTER  OF  GRAVITY) 

-2%  Lb  (-5.45%  MAC) 

LIFT/DRAG  MODULATION 

PEAK  SUBSONIC  VALUE  (GEAR  UP,  <5SB  = 0) 

NOT  LESS  THAN  4.4 

PEAK  SUBSONIC  VALUE  (GEAR  UP,  6S B = 85  DEG) 

NOT  LESS  THAN  2.5 

TABLE  2.-  SPACE  SHUTTLE  ORBITER  WIND  TUNNEL  UTILIZATION  SUMMARY 


TEST 


IDENTIFICATION 

FACILITY 

MODEL  SCALE 

TRANSONIC 

OA145A 

ARC  11  x 11  FT 

.05 

OA270A 

LaRC  16T 

.05 

OA270B 

LaRC  16T 

.02 

LA70 

CALSPAN  8 FT 

.015 

LA76 

LTV  4x4  HSWT 

.015 

LA77 

ARC  11  x 11  FT 

.015 

LA1 11 

LaRC  8 FT  TWT 

.015 

LA115 

LaRC  8 FT  TWT 

.015 

SUPERSONIC 

OA145B 

ARC  9 x 7 FT 

.05 

OA145C 

ARC  8 x 7 FT 

.05 

OA209 

AEDC “A” 

.02 

LA63A 

LaRC  UPWT-1 

.015 

LA63B 

LaRC  UPWT-2 

.015 

LA75 

LaRC  UPWT-2 

.015 

LA76 

LTV  4x4  HSWT 

.015 

LA101 

LaRC  UPWT-1 

.015 

LA110 

LaRC  UPWT-1 

.015 

LA114 

LaRC  UPWT-2 

.02 

LA125 

LaRC  UPWT-2 

.02 

LA131 

LaRC  UPWT-2 

.02 

LA144 

LTV  4 x 4 FT 

.02 

HYPERSONIC 

OA113 

CALSPAN  HST  (48  IN.) 

.01 

OA171 

NSWC  TUNNEL  9 

.02 

OA208 

AEDC  “B" 

.02 

OA257 

LaRC  20  IN. 

.01 

OA258 

AEDC  “B” 

.02 

OA259 

AEDC  “B” 

.01 
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ORfGfNAL  PAGE  tS 
OF  POOR  QUALITY 


TABLE  3.-  KEY  AERODYNAMIC  PARAMETERS 


AERODYNAMIC 

PARAMETER 

FLIGHT 

REGIME 

WHY  PARAMETERS 
ARE  SIGNIFICANT 

AERO  CONCERN  IN 
DEFINITION  OF  PARAMETERS 

L/O.Cm.Cmde 

ALL 

• CROSSRANGE 

• TERMINAL  AREA  ENERGY 
MANAGEMENT 

• ELEVON  REQUIRED  TO  TRIM 

• RCS  FUEL  USAGE 

• VISCOUS  INTERACTION  EFFECTS 

• FLOW  SEPARATION 

• REAL  GAS  EFFECTS  NOT 
SIMULATED  IN  WIND  TUNNEL 

HINGE  MOMENTS 

TRANSONIC 

• ACTUATOR  DESIGN 

• DEFINES  CONTROL  SURFACE 
STALL  AND  RATE  LIMITING 
CONDITIONS 

• WIND  TUNNEL  WALL,  BLOCKAGE, 
AND  SHOCK  REFLECTION  EFFECTS 

c"a«'  c'sa 

HIGH 

• AILERON  IS  USED  FOR  BOTH 

• CONTROL  SURFACE  INTERACTION 

SUPERSONIC 

ROLL  AND  YAW  TRIM  ABOVE 
MACH  3.5  BEFORE  RUDDER  IS 
ACTIVATED 
• RCS  FUEL  USAGE 

• EFFECT  OF  ELEVON  ON  AILERON 
EFFECTIVENESS 

Cn«a’C|6»’Cn«r’C|6r 

TRANSONIC/ 

• RUDDER  IS  USED  FOR  BOTH 

• CONTROL  SURFACE  INTERACTION 

SUPERSONIC 

YAW  AND  ROLL  TRIM 

FOR  1.5  <M  < 3.5 

• AILERON  COORDINATES  TURN 

• RCS  YAW  JET  IS  NEEDED 
UNTIL  RUDDER  IS  EFFECTIVE 

• DEFINES  SWITCH-OVER  POINT 
FROM  SPACECRAFT  TO 
AIRCRAFT  FCS  MODE 

• RUDDER  EFFECTIVENESS  AT 
HIGH  a AND  MACH 

• AEROELASTIC  EFFECTS 

• TRANSONIC  WIND  TUNNEL 
ACCURACIES 

Booster 


Launch  configuration 


FIGURE  1.-  TYPICAL  PHASE  A CONFIGURATION  CONCEPT. 
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FIGURE  2.-  TYPICAL  PHASE  B CONFIGURATION  CONCEPT, 


^KiGlMAL  PAGE  iS 

°F  POOR  QUALITY 


FIGURE  3.-  TYPICAL  PARALLEL  BURN  CONFIGURATION. 
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GROSS  LIFT-OFF  WEIGHT-2022.6  x 106g  (4459K  LB) 


ORBITER  68.5  x 106g  (151K  LB) 

SRB  (2)  1172.1  x 106g  (2584K  LB) 

ET  756.1  x 106g  (1667K  LB) 

PAYLOAD  (DOWN)  . . . 14.5  x 106g  (32K  LB 

(DESIGN)) 


76.6  FT 
(23.35  m) 


j i i i 

— l — l 

TT 

nt 

I i i i , 

_ -i  1 

Ji 

±fc 

35.0  FT 
"(10.67  m) 


•149.1  FT  (45.45  m)- 


■154.4  FT  (47.06  m)- 


•184.2  FT  (56.14  m)- 


FIGURE  4.-  SPACE  SHUTTLE  INTEGRATED  VEHICLE  FINAL  CONFIGURATION. 
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FIGURE  5.-  ORBITER  ENTRY  PHASES. 
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413  25 

FT2 

SPAN 

93668  IN 

315.72 
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02 

0.404 
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81/45  DEG 

45 
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DIHEDRAL 

35 

— 

INCIDENCE 

05  DEG 

— 

MAC 

47481  IN 

199.81 

IN. 

CONTROL 

SURFACE 

AREA 

(FT2) 

MAX  DEFLECTIONS 
(DEG) 

ELEVON  (1  SIDE) 

206  57 

-35  TO  +20 

BODY  FLAP 

135.75 

—11.7  TO  +22.5 

SPEEOBRAKE 

97  148 

OTO  87.2 

RUDDER 

97.148 

-22.8  TO  +22.8 

REFERENCE  CENTER  OF  GRAVITY 

0.65  Lb 
(X0  -1  076.7) 


Zn -372 


1290.3 

REF  BODY  LENGTH 


938.68 


NOTE.  ALL  DIMENSIONS  IN  INCHES 


FIGURE  60-  SPACE  SHUTTLE  ORBITER  FINAL  CONFIGURATION. 
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STABILITY 


MODERATE  FINENESS 
RATIO-SOFT  CHINE 
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HYPERSONIC,  TRIM, 
PERFORMANCE,  AND  HEATING 


FLARED  RUDDER  - SPEED  BRAKE 
• RUDDER  SIZED 
BY  CROSSWIND 
LANDING 


DOUBLE  DELTA  WING  (81°/45°;  - 
• SIZED  BY  171-KNOT  DESIGN 
VELOCITY 


FUSELAGE 

• SIZED  BY  PAYLOAD 
REQUIREMENTS 


ORBITAL  MANEUVERING 
SYSTEM  (OMS)  POD 
• SIZED  BY  TANKAGE 


BODY  FLAP 
• SIZED  TO  PROTECT 
SSME  FROM  ENTRY 
HEATING 


-FULL  SPAN  ELEVONS/AILERONS 
• SIZED  BY  HYPERSONIC  TRIM; 
PITCHDOWN  MANEUVER 


AFT  FUSELAGE 
• SIZED  BY  SPACE  SHUTTLE 
MAIN  ENGINES  (SSME) 


FIGURE  7.-  ORBITER  SIZING  CRITERIA. 
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CRITICAL  DESIGN  REVIEW  (CDR) 
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KSC  INITIAL  OPERATIONAL  CAPABILITY 
ORBITAL  FLIGHT  TEST  PROGRAM 
VAFB  INITIAL  OPERATIONAL  CAPABILITY 


FIGURE  8.-  SPACE  SHUTTLE  PROGRAM  MILESTONES. 
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FIGURE  9.-  ORBITER  CONFIGURATION  EVOLUTION. 
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FIGURE  10.-  SPACE  SHUTTLE  PROGRAMMATIC  PHASING. 
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FIGURE  11.-  TYPICAL  ORBITER  ENTRY  TRAJECTORY. 


PITCH-DOWN 
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FIGURE  12.-  REACTION  CONTROL  SYSTEM  (RCS). 
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FULL  SPAN  ELEVONS/ AILERONS 

• CONTROLLER  FOR  LONGITUDINAL 

STABILITY  AUGMENTATION 

• SHORT  PERIOD  LONGITUDINAL  TRIM 

• ROLL  CONTROL  AND  TRIM 


VERTICAL 

• DIRECTIONAL  STABILITY 

• CONTROL  EFFECTIVENESS 


FLARED  RUDDER-SPEED  BRAKE 

• L/D  MODULATION  AT 
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• SUPPLEMENTS  SUPERSONIC 
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AFT  REACTION 
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MODERATE  FINENESS 
RATIO-SOFT  CHINE 
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FORWARD 


REACTION  CONTROL  JETS 


FIGURE  13.-  ORBITER  FUNCTIONAL  CHARACTERISTICS. 
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FIGURE  14.-  USE  OF  RCS  AND  AEROSURFACES  BY  FCS. 
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FIGURE  15.-  INTERACTION  OF  RCS  JETS  WITH  VEHICLE  AND  FLOWFIELD. 
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FIGURE  16.-  SPACE  SHUTTLE  WIND  TUNNEL  PROGRAM. 
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FIGURE  17.-  ORBITER  WIND  TUNNEL  PROGRAM. 
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FIGURE  18.-  FACILITY  SIMULATION  CAPABILITY. 
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FIGURE  19.-  WIND  TUNNEL  VERIFICATION  TEST  PROGRAM. 
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FIGURE  20.-  WIND  TUNNEL  MODEL  FIDELITY. 
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(WING  = 96  PANELS) 


FIGURE  21.-  ORBITER  AERODYNAMIC  PANELING. 
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FIGURE  22.-  COMPARISON  OF  WIND  TUNNEL  WITH  THEORETICAL  PREDICTION  OF  THE 
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FIGURE  24.-  VARIATION  OF  VISCOUS  PARAMETER  ALONG  NOMINAL  ENTRY  TRAJECTORY. 
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FIGURE  25.-  EFFECT  OF  VISCOUS  INTERACTION  ON  NORMAL  AND  AXIAL  FORCE. 


a = 40,  <5qf  = 0 


-0.05 


Z 

UJ 


H -0.10 


UJ 

O 

O 


UJ 


-0.15 


6e 

-10 


10 


246 


(L/D)Trim 


70  80  90  100 

ALTITUDE  -10s  METERS 

FIGURE  28.-  EFFECT  OF  VISCOUS  INTERACTION  ON  c.g.  TRIM  CAPABILITY. 


247 


MACH  0.25 
ARC  40  X 80  DATA 


FIGURE  29.-  LOW-SPEED  LONGITUDINAL  CHARACTERISTICS. 


MACH  10  MACH  5 

O LaRC  UPWT 
□ AEDCA 

< AEDC  AND  CALSPAN  -fr  MSFC  14  TWT 


PITCHING  MOMENT,  Cm  PITCHING  MOMENT.  Cm 

FIGURE  30.-  LONGITUDINAL  CHARACTERISTICS  SUMMARY. 


248 


MACH  1.2 


MACH  0.6 


ARC  11  X 11  DATA 


PITCHING  MOMENT,  Cm  PITCHING  MOMENT,  Cm 

(b)  SUBSONIC/SUPERSONIC. 

FIGURE  30.-  CONCLUDED. 


OBLIQUE 
SHOCK 


(A) 


FIGURE  31.-  LEESIDE  FLOW  PATTERNS. 
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FIGURE  36.-  ORBITER  TRIM  LIMITS. 


FIGURE  37.-  ELEVON  DEFLECTION  SCHEDULE. 
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FIGURE  41.-  EFFECT  OF  ELEVON  ON  DIRECTIONAL  STABILITY. 
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FIGURE  42.-  EFFECT  OF  ELEVON  ON  DIHEDRAL  STABILITY. 
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FIGURE  49.-  HIGH  ALTITUDE  UNCERTAINTIES. 
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FIGURE  50.-  CORRELATION  OF  FLIGHT  WITH  PREDICTED  L/D. 
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FIGURE  53.-  CORRELATION  OF  FLIGHT  WITH  PREDICTED  AILERON  EFFECTIVENESS. 
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ABSTRACT 


The  approach  used  in  establishing  the  predicted  aerodynamic  uncertainties  and  the  process 
used  in  applying  these  uncertainties  during  the  design  of  the  Orbiter  flight  control  system  and 
the  entry  trajectory  is  presented.  The  flight  test  program  that  was  designed  to  verify  the 
stability  and  control  derivatives  with  a minimum  of  test  flights  is  presented  and  a comparison  of 
preflight  predictions  with  preliminary  flight  test  results  is  made.  It  is  concluded  that  the 
approach  used  for  the  Orbiter  is  applicable  to  future  programs  where  testing  is  limited  due  to 
time  constraints  or  funding. 


NOMENCLATURE 


A 

AN 

Ax 


Ay 


r 


Amplitude,  deg/sec  or  g's 
Normal  acceleration,  g's 
Axial  acceleration,  g's 
Lateral  acceleration,  g's 


Coefficient 

of 

roll 

due 

to 

sideslip,  per  deg 

Coefficient 

of 

roll 

due 

to 

aileron  deflection 

, per  deg 

Coefficient 

of 

roll 

due 

to 

rudder  deflection, 

per  deg 

Coefficient 

of 

yaw 

due 

to 

sideslip,  per  deg 

Coefficient 

of 

yaw 

due 

to 

aileron  deflection, 

per  deg 

Coefficient 

of 

yaw 

due 

to 

rudder  deflection. 

per  deg 

Coefficient 

of 

normal  force  due  to  elevon  deflection,  per  deg 

Pitching  moment  coefficient 

Pitching  moment  coefficient  at  0 angle  of  attack 

Coefficient  of  pitching  moment  due  to  bodyflap  deflection,  per  deg 
Coefficient  of  pitching  moment  due  to  elevon  deflection,  per  deg 

Coefficient  of  pitching  moment  due  to  angle  of  attack,  per  deg 
Coefficient  of  side  force  due  to  sideslip,  per  deg 

Coefficient  of  side  force  due  to  aileron  deflection,  per  deg 

Coefficient  of  side  force  due  to  rudder  deflection,  per  deg 
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B 

L/D 

M 

T 

V 
X 

Y 
Z 
a 
B 

6a 

5BF 


SB 


Body  length,  in. 

Lif t-to-drag  ratio 

Mach  number 

Time,  sec 

Velocity,  ft/sec 

Body  axis  axial  coordinate,  in. 

Body  axis  lateral  coordinate,  in. 

Body  axis  vertical  coordinate,  in. 

Angle  of  attack,  deg 

Sideslip  angle,  deg 

Aileron  deflection,  deg 

Bodyflap  deflection,  deg 
Elevon  deflection,  deg 
Rudder  deflection,  deg 
Speedbrake  deflection,  deg 
Standard  deviation 


q Dynamic  pressure,  psf 

<i>  Undamped  natural  frequency  of  the  dutch  roll  oscillation 

m Undamped  natural  frequency  of  the  numerator  of  (f)/6  transfer  function 

© ® 


ACRONYMS 


ACIP  Aerodynamic  Coefficient  Identification  Package 

eg  Center  of  gravity 

FCS  Flight  Control  System 

FSL  Flight  Software  Laboratory 

GN&C  Guidance,  Navigation  and  Control 

GPC  General  purpose  computer 

IMU  Inertial  Measurement  Unit 

LRU  Line  replaceable  unit 

MMLE3  Modified  maximum  likelihood  estimator,  version  3 

MXRCS  RCS  roll  moment 

MZRCS  RCS  yaw  moment 

POPU  Pushover  Pullup  Maneuver 

PTI  Programmed  test  input 

RCS  Reaction  control  system 

SPS  Shuttle  Procedures  Simulator 

STS  Space  Transportation  System 

STS-1  First  Flight  of  the  Space  Shuttle 

STS-2  Second  Flight  of  the  Space  Shuttle 

WOW  Worse  on  worse  combination  of  errors 


INTRODUCTION 


The  decision  to  perform  an  orbital  manned  mission  on  the  first  Shuttle  launch  presented 
several  challenges  to  the  entry  design  community.  A significant  challenge  was  presented  by  the 
question  of  how  to  maximize  safety  (man  rate  the  system)  on  the  first  flight  considering  the 
parallel  development  of  the  aerodynamics  and  the  Flight  Control  System  (FCS).  A challenge  was 
also  presented  in  setting  up  a flight  test  program  for  a vehicle  that  was  flying  through  a 
continuously  changing  environment.  Finally,  because  of  cost  and  operational  constraints,  the 
question  of  how  to  develop  an  operational  vehicle  with  a minimum  flight  test  program  became  a 
large  challenge.  This  paper  will  address  how  these  challenges  were  successfully  met. 


AERODYNAMIC  VARIATIONS  DEVELOPMENT 


The  challenge  of  maximizing  safety  on  the  first  flight  led  to  development  of  a reasonable 
estimate  of  maximum  possible  errors  in  the  preflight  predicted  aerodynamics  which  were  used  to 
certify  the  FCS  prior  to  the  first  flight.  The  best  approach  for  the  development  of  these  errors 
which  were  called  variations,  was  concluded  to  be  an  analysis  of  the  wind  tunnel  to  flight  test 
differences  of  previous  aircraft  programs.  Unfortunately,  the  verification  of  preflight  predicted 
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aerodynamics  was  not  a major  objective  of  most  of  the  previous  flight  test  programs.  This 
severely  limited  the  amount  of  data  available  for  conducting  flight  test  to  wind  tunnel 
comparisons.  The  flight  data  base  was  further  limited  by  restricting  the  comparison  to  those 
vehicles  which  were  geometrically  similar  to  the  Orbiter.  Those  vehicles  chosen  as  applicable  to 
the  Orbiter  are  presented  in  table  1.  Also  presented  are  geometric  factors  and  other 
considerations  pertinent  to  the  vehicle  configuration  choices. 

Variations  were  established  by  fairing  the  differences  between  the  flight  and  predicted 
aerodynamics  as  a function  of  Mach  number.  The  selections  of  the  configurations  and  the  fairing 
process  are  very  subjective  in  nature.  For  this  reason,  a team  of  aerodynamicists  from  the 
various  NASA  centers,  the  Air  Force  and  the  contractors  was  formed  to  conduct  the  analysis  and 
reach  a consensus  on  variations. 

The  team's  flight-to-predicted  correlation  and  their  recommended  variations  fairings  are 
presented  in  reference  1.  A more  detailed  development  is  presented  in  reference  2.  The 
development  of  a less  severe  set  of  uncertainties  (tolerances)  based  on  the  repeatability  of  wind 
tunnel  tests  is  also  presented  in  reference  1. 

Reaction  control  jet  plume  interaction  variation  development  is  reviewed  in  reference  3. 


THE  CORRELATION  OF  AERODYNAMIC  VARIATIONS 


A total  of  9 lateral  directional  coefficients  (3  each  beta,  aileron  and  rudder  derivatives) 
were  defined  for  application  to  the  Orbiter  entry  FCS  verification.  Use  of  all  possible 
combination  of  signs  and  variations  for  these  9 coefficients  would  have  resulted  in  an  impossible 
number  of  cases  to  analyze  and  simulate.  Therefore,  considerable  attention  was  devoted  to 
identifying  the  more  critical  combination  of  coefficient  variations  for  use  in  FCS  verification. 

In  addition,  an  alternative  to  a worse-on-worse  (WOW)  analysis  was  desirable  to  provide  a 
less  demanding  and  possibly  more  realistic  result  for  formal  verification.  The  initial  step  in 
reducing  the  WOW  case  was  to  define  any  sign  correlation  that  might  exist  between  coefficient 
variations  based  on  the  physical  relation  of  the  coefficients. 


Reference  4 presents  the  details  involved  in  defining  the  correlation  coefficients. 
Correlations  were  established  for  the  sideslip,  aileron  and  rudder  derivatives.  For  the 
correlated  coefficients,  99  percentile  ellipses  were  established  from  the  equation 


1 = (1  - p ) 
xy 


X x 2 


2p  (TT-)  (TT-) 

xy  3a  3a 
J x y 


X and  Y are  the  correlated  coefficients,  0 and  a are  the  standard  deviations  and  p is  the 

x y xy 

linear  correlation  coefficient  which  varies  between  zero  and  one.  Stated  from  a probability 
standpoint  there  is  a one  chance  in  a hundred  that  a combination  of  errors  in  X and  Y would  lie 
outside  the  locus  of  the  99  percentile  ellipse. 

Figure  1 presents  an  example  of  correlations  in  the  yawing  moment  and  rolling  moment  sideslip 
coefficients.  The  vector  from  the  origin  represents  the  nominal  value  for  C and  C.  while  the 

(3 

rectangle  represents  the  3a  variations.  The  different  ellipses  inside  the  rectangle  show  the 
effect  of  varying  the  correlation  from  0 to  a highly  correlated  value  of  .9.  Results  from  wind 
tunnel  tests  were  used  to  establish  the  correlation  coefficients. 


APPLICATION  OF  AERODYNAMIC  VARIATIONS 


A programmatic  decision  was  made  to  use  aerodynamic  variations  in  the  Orbiter  FCS  design 
evaluation  and  verification  process.  For  the  initial  FCS  design  evaluation  and  simulation 
studies,  a "worst  on  worst"  combination  of  variations  was  used.  For  the  formal  entry  verification 
at  the  Flight  Software  Laboratory  (FSL)  at  Rockwell,  variation  sets  were  used  which  correlated  the 
roll  and  yaw  moment  coefficients  for  the  sideslip,  aileron  and  rudder  coefficients. 

Because  of  the  wide  range  of  flight  conditions  the  Orbiter  was  to  encounter  during  the  first 
reentry  flight  test,  it  was  required  to  evaluate  as  many  combinations  of  aerodynamic  uncertainties 
as  possible.  However  it  was  also  desirable  to  select  a more  limited  set  of  uncertainties  for 
concentrated  analysis  and  simulation  efforts.  It  thus  became  necessary  to  define  those 
aerodynamic  uncertainty  combinations  that  presented  the  most  potential  problems  to  the  Orbiter  and 
to  make  certain  that  the  flight  control  system  could  maintain  control  of  the  Orbiter  with  these 
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combinations.  In  the  initial  FCS  evaluation,  a total  of  26  lateral  directional  variation  sets 
were  evaluated  in  a series  of  almost  600  piloted  simulation  runs  on  the  Shuttle  Procedures 
Simulator  (SPS)  at  the  Johnson  Space  Center  (JSC).  These  26  cases  were  selected  using  various 
trim,  controllability  and  handling  qualities  criteria.  Based  on  the  results  of  these  simulation 
runs  plus  additional  trim  and  stability  analyses,  a subset  of  7 cases  were  chosen  and  used  for  the 
majority  of  the  formal  verification  process. 

Figure  2 shows  a vector  diagram  of  the  aero  coefficients  and  RCS  jets  for  the  roll  and  yaw 
axes  at  Mach  3.5.  The  numbers  shown  on  the  diagram  indicate  the  nomenclature  used  for  identifying 
the  7 cases  selected  for  the  verification  process.  The  corners  shown  indicate  the  WOW  or 
"rectangular”  variation  sets  which  were  used  in  the  FCS  development  while  the  ellipses  represent 
the  correlated  variations.  The  elliptical  variation  sets  were  generally  selected  from  points  on 
the  ellipses  that  were  close  to  the  rectangular  counterparts.  Some  of  the  history  and  logic 
involved  in  the  selection  of  the  cases  used  for  the  FCS  verification  will  now  be  discussed. 


LCDP  AND  C DYNAMIC 
n 
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A significant  portion  of  the  analysis  devoted  to  aerodynamic  variations  was  applied  to 
variation  sets  19  and  20.  Variation  set  19  represented  the  most  severe  case  for  the  Lateral 

Control  Departure  Parameter  (LCDP).^  During  the  early  stages  of  the  Orbiter  development,  most  of 
the  reentry  was  performed  using  an  all  aerodynamic  control  concept.  Prior  to  rudder  activation 
which  then  occurred  around  Mach  5,  the  aileron  was  the  only  aerodynamic  control  effector  for 
lateral  directional  control  and  trim.  A reverse  aileron  control  that  required  a negative  value 

for  the  LCDP,  C C0  - C0  C <0,  was  utilized  prior  to  rudder  activation. ^ The  lateral  trim 
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logic  was  also  configured  so  that  a negative  value  of  the  LCDP  was  required  prior  to  rudder 
activation.  Some  of  the  early  simulations  using  aerodynamic  uncertainties  on  the  aileron  and  beta 
derivatives  resulted  in  lateral  trim  and  controllability  problems  prior  to  rudder  activation. 
Analysis  indicated  that  the  problem  was  caused  by  a sign  change  in  the  LCDP  in  the  Mach  5 region. 
As  a partial  result  of  this  problem,  several  changes  were  made  to  the  FCS.  The  basic  FCS  design 
was  changed  from  the  aileron  bank  control  to  a system  utilizing  the  yaw  RCS  jets  to  initiate  bank 

maneuvers  and  the  ailerons  to  coordinate  the  maneuvers  prior  to  activation  of  the  rudder.^  After 
the  rudder  became  active,  a gradual  FCS  gain  change  produced  the  conventional  aileron  bank  control 
with  rudder  coordination. 

Since  use  of  the  yaw  jets  for  trim  would  result  in  excessive  propellant  requirements,  the 
aileron  was  still  required  for  trim.  To  improve  the  aileron  trim  capability  in  the  critical  Mach 
region,  changes  were  made  to  the  angle  of  attack  and  elevon  schedules.  With  aero  variations 
applied,  Mach  3.5  was  the  highest  Mach  number  that  the  rudder  could  be  considered  effective  and 
this  Mach  number  was  chosen  as  the  activation  point  for  the  rudder.  It  was  then  considered  a 
requirement  that  aileron  trim  be  available  down  to  Mach  3.5  with  minimal  yaw  RCS  requirements. 

Figure  3 shows  the  sensitivity  of  the  Orbiter  LCDP  to  angle  of  attack  for  several  Mach 
numbers  with  the  worst  case  aero  variations  applied.  It  is  obvious  that  in  the  Mach  greater  than 

3 region  an  angle  of  attack  of  more  then  15°  is  desirable  in  order  to  maintain  a negative  LCDP. 

The  early  flights  of  the  Orbiter  were  tailored  so  that  the  angle  of  attack  remained  above  15°  for 
Mach  greater  than  3.5. 

Another  significant  factor  in  the  LCDP  is  the  elevon  trim  position.  This  is  due  to  the 
effect  of  elevon  position  on  the  aileron  derivatives.  A desired  elevon  trim  position  of  +5° 

(down)  was  eventually  selected  for  STS-1  in  the  Mach  3-4  region.  In  the  higher  Mach  region  where 
elevon  heating  is  a concern,  the  elevon  was  scheduled  at  -1  degree  (up)  and  in  the  transonic 
region  where  there  was  some  concern  about  hinge  moments,  a schedule  close  to  zero  was  selected. 

The  elevon  position  is  maintained  by  the  bodyflap  through  a feedback  from  the  elevon  which  drives 
the  bodyflap  to  maintain  the  pre-set  elevon  schedule. 

Application  of  the  LCDP  in  the  Mach  range  from  approximately  3-8  was  a driver  in  the  angle  of 
attack,  elevon  and  speedbrake  schedules  as  well  as  the  longitudinal  eg  choice  for  STS-1. 

In  the  longitudinal  axis  the  primary  problem  associated  with  aero  uncertainties  was  the 
pitching  moment  uncertainty,  Cffl  and  its  effect  on  elevon  trim  position.  Figure  4 shows  the  pre 
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STS-1  capability  to  position  the  elevon  for  the  design  eg  body  length  extremes  of  65  percent 
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(forward)  and  67.5  percent  (aft)  with  pitching  moment  variations  and  with  the  bodyflap  positioned 
at  its  extreme  limits  to  aid  the  desired  trim.  Also  shown  on  figure  4 is  the  STS-1  elevon 

schedule.  It  is  obvious  that  with  C variations  the  Orbiter  could  not  achieve  the  desired  elevon 

m 

schedule  over  the  design  range  of  cg's.  Based  on  the  desired  elevon  schedule  and  the  effect  of 
pitching  moment  variations,  the  STS-1  eg  was  selected  at  66.7  percent  body  length.  Figure  5 shows 
the  elevon  envelope  at  the  66.7  percent  eg  with  variations  while  figure  6 shows  the  effect  of 

eg  on  the  LCDP  at  Mach  3.5  for  the  worst  case  variation  set.  The  eg  envelope  adopted  for  STS-1 
mission  rules  is  shown  in  figure  7 . 


Variation  set  20  created  the  minimum  value  for  C dynamic  which  is  defined  as  C cosa  - 

n8  8 


C0  sina  . C dynamic  is  the  stability  term  for  coupled  lateral  directional  motion  and  it  was 
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considered  a requirement  to  have  a stable  value  for  this  parameter  throughout  entry.  Figure  8 
shows  C dynamic  in  the  lower  Mach  region  for  variation  set  20  for  lg  flight  at  7.5°  a.  The 
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unaugmented  C dynamic  is  unstable  from  about  Mach  1.2  to  3.2  at  these  flight  conditions. 
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The  Orbiter  FCS  utilizes  a side  acceleration  feedback  to  the  rudder  and  yaw  jets  to  provide 
stability  augmentation.  An  approximate  3 feedback  gain  to  the  rudder  can  be  computed  and  from 
this  gain  a rudder  "augmented  dynamic"  can  be  calculated.  For  the  Mach  2 region  the 
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equivalent  gain  for  3 feedback  to  the  rudder  is  approximately  -1.5  to  -2.  Additional  augmentation 
is  provided  by  the  yaw  RCS  jets  and  although  the  system  is  nonlinear,  an  approximation  to  an 
augmented  dynamic  can  be  obtained  which  is  valid  for  sideslip  angles  less  than  that  required 


to  fire  all  4 jets  (approximately  1°  to  2°).  The  effective  C dynamic  for  both  rudder  and  RCS 
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augmentation  is  shown  in  figure  8.  Very  little  improvement  is  shown  for  the  rudder  augmentation. 
This  is  due  to  the  small  rudder  effectiveness  which  results  from  the  aeroelasticity  effects  and 
from  application  of  aerodynamic  variations.  It  is  evident  that  the  RCS  provides  a significant 
improvement.  However  after  the  jets  are  saturated  additional  augmentation  is  not  available  and 
there  is  a 8 limit  beyond  which  control  is  not  possible.  For  STS-1,  angle  of  attack  and  dynamic 


pressure  limits  were  established  based  on  the  ability  of  2 yaw  jets  to  control  the  Orbiter  at  1.5° 
sideslip  for  the  worst  case  aero  variations.  Figure  9 shows  the  lower  angle  of  attack  boundary 
established  for  the  flight  rules  based  on  lateral  trim  concerns  above  Mach  3 and  Cn  dynamic 
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concerns  below  Mach  3.  In  the  Mach  2 region  STS-1  had  a dynamic  pressure  limit  of  250  psf 
programmed  into  the  guidance  laws  and  the  trajectory  was  shaped  to  provide  ample  margin  above  the 
lower  alpha  limits. 


ADDITIONAL  CRITERIA 


While  the  aero  variation  sets  associated  with  the  LCDP  and  with  C^  dynamic  received 
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considerable  attention  during  the  FCS  design  and  verification  process,  other  combinations  of 
variations  shown  on  figure  2 were  also  extensively  analyzed.  Diagrams  similar  to  figure  2 were 


widely  used  in  helping  to  select  which  variation  sets  to  use  at  different  flight  conditions.  This 
was  particularly  true  of  cases  involving  co-alignment  of  effectors  and  stability  derivatives.  For 
example,  with  the  variation  set  19,  the  beta  and  aileron  vectors  align  which  corresponds  to  the 
LCDP  going  to  zero.  This  results  in  the  loss  of  aerodynamic  lateral  trim  capability  and  would 
require  the  use  of  yaw  jets  to  trim.  Variation  set  19  was  used  for  the  worst  case  LCDP  analysis* 
Variation  set  20  was  used  for  the  minimum  C^  dynamic  case  and  results  in  both  minimum  3 stability 


and  rudder  effectiveness.  Variation  set  20  resulted  in  another  problem  at  higher  Mach  numbers 

which  required  a change  to  the  FCS.  At  the  hypersonic  Mach  numbers  and  40°  angle  of  attack  when 
variations  were  applied  to  1 yaw  jet,  a coalignment  of  the  jet  and  3 vectors  occurred  due  to  a 
counter  clockwise  rotation  of  the  jet  vector.  Since  the  bank  control  is  achieved  through  the 
combination  of  jets  and  3,  a control  criteria  similar  to  the  LCDP  results.  The  form  of  this 
criteria  used  for  the  Orbiter  was  C - C0  M >0.  With  one  yaw  jet  firing  a control 
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reversal  resulted  which  was  similar  to  the  case  for  the  aileron  control  problem  associated  with 
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the  LCDP.  As  a result  of  this  problem,  the  FCS  was  changed  so  that  a minimum  of  two  yaw  jets  were 
always  fired.  Another  case  that  received  considerable  attention  was  variation  set  12  which  is  a 
high  gain  case  utilizing  the  most  stable  sideslip  derivatives  in  combination  with  the  most 
effective  control  surfaces  and  jets.  This  case  provided  a balance  for  the  low  g°.in  cases  and 
resulted  in  FCS  gains  that  covered  the  potential  extremes  in  the  aero  variations.  Case  9 was 
similar  to  case  20,  but  in  the  presence  of  large  winds  around  Mach  5,  a long  period  oscillation 
was  observed  under  certain  flight  conditions.  Offline  stability  analysis  indicated  the  more 
negative  C associated  with  variation  set  9 was  resulting  in  a system  approaching  neutral 


stability . 


In  general  cases  2,  11,  and  23  produced  less  severe  problems  than  the  previously  mentioned 
cases  and  were  eventually  dropped  from  the  formal  verification  for  STS-2.  Case  2 was  originally 

2 

selected  because  it  produced  the  largest  value  for  (ah/u),)  and  there  was  some  concern  about 
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creating  pilot  induced  oscillations  (PIO)  with  this  set  of  variations.  However,  there  was  no 
indication  in  any  of  the  piloted  simulations  that  this  case  produced  any  PIO  tendencies.  Case  11 
was  originally  selected  because  it  was  thought  to  give  the  minimum  value  of  the  LCDP  for  the 
conventional  aileron  control  mode.  However,  in  the  critical  Mach  region  around  Mach  2,  case  9 
usually  resulted  in  a lower  value  of  the  LCDP.  Case  23  was  selected  because  it  generated  a 
maximum  sideslip  angle  during  the  high  heating  region. 


A problem  that  was  observed  with  cases  9,  11  and  23  was  an  occasional  tendency  for  the 
aileron  and  rudder  to  trim  against  each  other  after  the  rudder  became  active.  From  figure  2 it 
can  be  observed  that  the  aileron  and  rudder  vectors  are  almost  co-aligned  for  these  cases  and  is 
the  probable  cause  for  the  trim  problem.  A procedure  was  utilized  for  STS-1  which  required  the 
crew  to  check  the  trim  after  the  rudder  became  active  and  to  trim  the  aileron  back  toward  zero  if 
a force  fight  resulted  between  the  aileron  and  rudder. 


FCS  VERIFICATION  PROCESS 


The  570  piloted  simulated  runs  on  the  Shuttle  Procedures  Simulation  at  JSC  were  completed  in 
December  1977  and  uncovered  several  significant  problems  when  the  variation  sets  were  applied. 
Several  changes  were  made  to  the  FCS  and  another  series  of  simulations  were  made  in  April  and  May 
of  1978.  The  modified  FCS  was  able  to  maintain  control  of  all  combinations  of  aerodynamic 
variations  except  for  one  case  in  the  Mach  6 region.  This  problem  occurred  when  a variation  set 
with  minimum  values  of  C dynamic  was  combined  with  large  winds  resulting  in  errors  in  the 
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navigation  derived  angle  of  attack.  Because  angle  of  attack  terms  are  present  in  the  bank 
coordination  logic  of  the  FCS,  errors  in  the  angle  of  attack  result  in  miscoordination  during  bank 
maneuvers  and  a resulting  buildup  in  sideslip  angle.  If  RCS  jet  failures  occurred,  control 

problems  resulted  for  angle  of  attack  errors  greater  than  approximately  3°.  In  order  to 
accommodate  this  problem  the  flight  rules  for  the  early  flights  required  manual  bank  reversals  at 
reduced  roll  rates  in  the  Mach  6 region  if  RCS  jet  failures  occurred. 

The  formal  integrated  guidance,  navigation  and  control  (GN&C)  verification  testing  began  at 
the  FSL  in  September  1979.  A total  of  35  runs  were  made  before  the  simulation  was  suspended  due 
to  several  significant  problems  that  resulted.  Forty-one  flight  software  anomalies  were 

identified  of  which  21  were  related  to  the  FCS.  In  general  the  problems  occurring  on  the  FSL  had 
not  been  observed  in  the  non  integrated  FCS  simulations  or  were  of  a much  smaller  magnitude.  As  a 
result  of  the  FSL  results  extensive  analysis  of  the  FCS  was  done  to  attempt  to  identify  and 
correct  the  observed  anomalies.  The  launch  schedule  slip  due  to  the  loose  tile  problem  provided 
the  FCS  community  an  opportunity  to  perform  a major  review  of  the  FCS  design.  Some  of  the 
problems  were  related  to  excessively  large  uncertainties  applied  to  the  GN&C  line  replaceable 
units  (LRU)  and  some  related  to  the  FSL  models.  However  some  FCS  changes  were  required  to  handle 
the  aero  variations  and  the  Orbiter  Software  Control  Board  approved  the  change  requests  in  April 
1980. 


Figure  10  shows  the  test  matrix  that  was  proposed  for  the  final  FCS  verification.  The  matrix 
includes  aerodynamic  uncertainties,  winds,  and  tolerances  on  the  GN&C  LRU's.  Most  of  the 
simulation  runs  were  performed  using  the  upper  left  box  (nominal)  and  the  lower  right  box  (worst 
case).  Figure  11  outlines  the  verification  process  that  was  approved  by  the  Orbiter 
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Configuration  Control  Board  (CCB)  prior  to  the  final  integrated  verification  testing  at  the  FSL. 
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The  GN&C  first  was  tested  with  nominal  aerodynamics  and  then  with  the  variations.  If  no 
problems  occurred  with  worst  case  variations,  verification  was  considered  complete.  If  problems 
resulted  with  variations,  the  case  was  repeated  with  tolerances.  If  the  system  could  not  handle 
tolerances,  a design  change  was  required  and  the  process  repeated.  A case  that  passed  with 
tolerances  but  failed  with  variations  resulted  in  a review  with  the  aero  group  to  discuss  the 
validity  of  the  specific  variation  case.  The  problem  was  then  presented  to  the  CCB  who  made  the 

decision  to  either  accept  the  risk  associated  with  the  case  or  to  require  a design  change. 

Formal  verification  was  done  on  the  FSL  in  August  and  September  of  1980.  The  GN&C 
performance  was  greatly  improved  compared  to  the  previous  verification  runs.  A week  long  post 
simulation  review  by  personnel  from  Rockwell,  Honeywell,  and  JSC  was  conducted  to  thoroughly 
analyze  the  results  of  each  run.  A total  of  16  anomalies  were  identified,  but  most  of  these  were 

relatively  minor  and  required  no  substantive  action.  The  most  significant  problems  were 

associated  with  the  low  C dynamic  cases  in  the  presence  of  design  case  winds  around  Mach  5.  The 
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program  managers  eventually  accepted  these  cases  after  it  was  shown  that  the  design  winds  for  the 
STS-1  flight  date  of  April  resulted  in  less  severe  problems  than  the  worst  case  winds  used  for  the 
FSL  verification.  The  flight  rule  requiring  manual  bank  maneuvers  in  this  Mach  region  following 
RCS  jet  failures  also  tended  to  alleviate  the  problem.  Based  on  the  results  of  the  verification 
process  the  GN&C  community  had  a high  degree  of  confidence  as  the  Orbiter  entered  the  flight  test 
program. 


FLIGHT  TESTING  CHALLENGE 


Stability  and  control  testing  of  the  Space  Shuttle  is  driven  by  conflicting  program  desires, 
while  limited  by  unique  problems.  Space  Shuttle  flights  are  very  costly  when  compared  with  test 
flights  of  other  aircraft.  There  is  an  intense  desire  within  the  program  to  bring  the  Shuttle  to 
an  operational  mode,  where  payloads  can  begin  to  make  the  Shuttle  cost  effective.  On  the  other 
hand  it  is  important  to  assure  the  safety  of  entry  flight  and  to  identify  the  real  limitations  of 
the  Shuttle  through  flight  testing.  This  conflict  in  goals  has  resulted  in  the  need  for  a minimum 
amount  of  highly  productive  testing. 

Conventional  flight  test  techniques  and  computer  programs  have  formed  the  basis  for  the 
Shuttle  flight  test  program.  Modifications  to  these  techniques  have  been  necessary,  however,  due 
to  the  inherent  constraints  in  Shuttle  testing.  Measures  have  been  taken  to  ensure  the  quality  of 
maneuvers  and  the  data  from  them,  so  that  the  number  of  repeat  maneuvers  can  be  minimized. 

The  flight  test  plan  developed  for  the  Shuttle  contains  very  few  test  points  when  compared  to 
test  programs  of  military  aircraft.  Enough  maneuvers  are  scheduled  only  to  verify  the  safety  of 
the  Shuttle  entry;  not  enough  to  build  a flight  test  data  base.  Where  significant  differences 
exist  between  the  flight  data  and  the  wind  tunnel  data  base,  further  test  points  are  scheduled. 

The  stability  and  control  derivatives  are  obtained  from  the  onboard  sensor  data  through  the 
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MMLE3  parameter  identification  program.  This  program  was  developed  at  Dryden  Flight  Research 
Facility  and  is  a state-of-the-art  method  of  extracting  derivatives  from  flight  data.  MMLE3  is 
the  latest  version  of  a program  which  has  been  used  in  many  test  programs  for  all  types  of 
aircraft . 

Derivative  deltas  calculated  between  flight  and  values  from  the  Shuttle  Aerodynamic  Design 

Data  Book^  are  provided  to  Shuttle  simulators  to  demonstrate  the  safety  of  further  testing  on 
upcoming  flights  and  to  assure  the  safety  of  flying  cg's  associated  with  planned  payloads. 


TEST  REQUIREMENTS 

Aerodynamic  test  requirements  have  arisen  from  two  sources.  The  original  source  is  the 
preflight  wind  tunnel  data  and  the  associated  aerodynamic  variations.  The  other  source  of 
requirements  is  the  flight  data  from  the  initial  flights,  during  which  anomalies  occurred.  The 
types  of  problems  identified  involve  either  potentially  excessive  RCS  fuel  usage  for  longitudinal 
and  lateral  trim,  or  potential  loss  of  control. 


PREFLIGHT  TEST  REQUIREMENTS 

Preflight  wind  tunnel  data  for  the  Orbiter  is  very  extensive  and  coupled  with  the  FCS 
verification  process  provided  sufficient  confidence  to  fly  the  initial  missions  under  benign 

conditions  and  within  a limited  range  of  x eg11.  However,  at  the  eg  extremes,  analysis  indicated 
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combinations  of  uncertainties  in  pitching  moment  and  the  stability  and  control  derivatives 
resulted  in  potential  control  problems.  These  potential  problems  resulted  in  the  establishement 
of  the  entry  flight  placards  on  angle  of  attack,  dynamic  pressure  and  x eg  mentioned  previously. 
Figure  12  shows  the  preflight  areas  of  concern  identified  on  a typical  Mach-alpha  profile. 

From  entry  interface  to  a dynamic  pressure  of  20  lbs  per  sq  ft,  uncertainties  in  basic 
pitching  moment  and  in  pitch  jet,  bodyflap,  and  elevon  effectiveness  indicated  a possible  problem 
in  longitudinal  trim  at  the  eg  extremes.  Such  a trim  problem  would  result  in  excessive  use  of  RCS 
fuel  by  the  pitch  jets. 

From  Mach  7 to  3,  uncertainty  in  the  LCDP  was  the  primary  concern.  Since  the  LCDP  changes 
signs  in  this  Mach  region,  the  FCS  gains  were  designed  to  provide  a transition  from  a mode 
requiring  a negative  LCDP  to  a conventional  aircraft  control  mode  requiring  a positive  LCDP. 

Since  the  exact  location  of  the  sign  change  in  the  LCDP  is  unknown  there  is  a requirement  for 
identifying  the  aerodynamic  coefficients  in  the  LCDP  and  determining  the  effects  of  the  elevon  and 
eg  position  on  these  coefficients. 


In  the  region  from  Mach  3 to  1,  C^ 


B 


dynamic  was  a concern,  particularly  for  trajectories 


resulting  in  large  dynamic  pressures.  C dynamic  was  also  a concern  in  the  Mach  5-8  region  for 
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high  wind  cases  that  produced  an  error  in  the  navigation  derived  angle  of  attack.  After  the 
rudder  becomes  active  at  Mach  3.5,  the  combined  lateral  trim  characteristics  of  the  aileron  and 
rudder  were  of  particular  interest. 


Flight  testing  is  planned  between  Mach  numbers  of  .9  and  .75  due  to  reduced  rudder 
effectiveness  at  minimum  speedbrake  settings.  The  rudder  is  aft  of  the  maximum  thickness  point  on 
the  vertical  tail,  and  effects  of  the  flow  past  the  rudder  panels  become  less  certain  with  a 
closed  speedbrake. 


FLIGHT  TEST  REQUIREMENTS  FROM  FLIGHT  DATA 


Anomalies  in  the  actual  flight  data  have  extended  the  test  requirements  as  originally 
conceived.  These  anomalies  have  in  some  cases  accentuated  the  need  for  certain  data  already  in 
the  flight  test  plan.  Others  have  pointed  to  a need  for  more  concentrated  investigation  of 
certain  flight  regimes.  A summary  of  flight  anomalies  are  shown  in  figure  12,  items  1 through  7. 

During  the  initial  bank  maneuver  on  flight  1 , at  a dynamic  pressure  of  14  lbs  per  sq  ft,  a 
large  oscillation  occurred  in  sideslip.  Studies  have  indicated  that  the  primary  cause  was  a 

12 

missed  prediction  in  roll  due  to  yaw  jet  firing. 


Another  flight  anomaly  is  a longitudinal  trim  difference  from  what  was  predicted.  This 
occurs  both  in  the  hypersonic  regime  with  a pitch  up  difference  and  in  the  transonic  regime,  where 

1 2 

the  difference  is  a pitch  down  moment.  Because  the  pitching  moment  anomaly  causes  more  up  (-) 
elevon  trim  transonical ly , the  aileron  effectiveness  data  required  in  this  regime  has  become  even 
more  important.  The  hypersonic  anomaly  has  caused  an  increased  need  for  longitudinal  stability 


and  control  data  to  ascertain  the  contributions  of  C 


and  C to  this  problem. 
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Figure  13  indicates  the  range  of  elevon  settings  required  for  trim  based  on  attributing  the 
pitching  moment  difference  to  C alone. 


Causing  additional  interest  in  the  Mach  2 to  1 regime  is  an  anomaly  which  has  been  observed 
on  the  first  five  flights.  The  anomaly  is  in  the  form  of  an  undamped  low  amplitude  roll 
oscillation,  which  has  a frequency  of  approximately  1/4  hertz.  This  problem  has  not  resulted  in 

. . . . 12 
additional  test  requirements,  since  intensive  testing  is  already  planned  for  this  regime. 

Additional  stability  and  control  testing  in  the  hypersonic  regime  has  resulted  from  STS-1 
data.  These  data  indicated  that  lateral  stability  was  different  than  expected.  Specifically  C 

nf 

was  more  (+)  than  expected.**’  *"*’  *^  In  addition,  aileron  trim  was  observed  to  have  an  offset 
between  Mach  18  and  7.  This  offset  has  been  observed  to  change  signs,  indicating  possible  flow 
asymmetries . 
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Another  important  anomaly  has  occurred  hypersonically . Above  Mach  10,  where  the  elevon 
schedule  has  been  varied  between  -1  and  +5  on  flights  1-4,  the  flight  data  indicate  that  the 
aileron  is  more  effective  than  predicted  at  positive  elevon  deflections.  The  data  also  indicate 

the  effectiveness  to  be  close  to  nominal  at  0°  elevon  setting.  While  this  is  beneficial  for 
positive  deflections,  the  trend  indicates  that  the  aileron  may  be  less  effective  at  negative 
deflections.  This  accentuates  the  need  for  data  which  will  clarify  the  dependence  of  aileron  on 
elevon  deflection. 

These  anomalies  have  not  restricted  the  flight  placards  further.  However,  they  have 
emphasized  the  need  for  data  in  certain  flight  regimes.  They  have  also  caused  the  planning  of 
further  testing  in  specific  areas. 


SHUTTLE  FLIGHT  TEST  PROGRAM 


The  Shuttle  test  program  is  the  product  of  significant  planning  and  integration  with  other 
program  requirements.  The  flight  test  requirements  from  wind  tunnel  uncertainties  and  flight 
anomalies  dictated  the  flight  conditions  at  which  maneuvers  would  be  done.  Sufficient  maneuvers 
were  planned  at  nominal  conditions  to  indicate  repeatability  of  results.  Additional  maneuvers 
were  planned  over  the  ranges  of  elevon  and  angle  of  attack  that  will  be  seen  operationally  to 
check  coefficient  sensitivities  to  these  parameters.  The  test  plan  has  been  modified  to  provide 
additional  information  in  areas  where  anomalies  have  occurred.  This  is  necessary  to  establish  an 
understanding  of  the  anomaly  and  to  develop  a data  base  for  simulators  in  areas  where  the  wind 
tunnel  data  is  deficient. 

The  tests  planned  for  each  flight  are  limited  by  the  nature  of  the  Shuttle  entry  and  by  other 
program  requirements.  Only  one  maneuver  at  each  flight  condition  is  possible  on  a given  flight, 
since  the  Shuttle  glides  from  400,000  ft  in  altitude  at  Mach  25  to  touchdown  in  the  span  of  30 
minutes.  The  crew  has  monitoring  functions  and  other  tasks  during  entry  that  also  limit  the 
number  of  maneuvers  that  can  be  performed.  This  has  resulted  in  a limit  of  8 to  10  maneuvers  per 
flight  and  in  a ground  rule  which  requires  that  maneuvers  be  spaced  to  the  satisfaction  of  the 
flight  crew.  Another  limitation  is  the  amount  of  RCS  fuel  available  for  doing  maneuvers.  Entry 

tests  must  compete  in  priority  with  other  mission  objectives  for  RCS  fuel.  This  includes  on-orbit 

activities  such  as  rendezvous  tests  and  payload  deployment.  Other  entry  tests  such  as  structural 
flutter  tests  and  aerothermal  pushover  pullup  teat  maneuvers  (POPU)  have  taken  priority  over 
stability  and  control  maneuvers,  because  instrumentation  for  these  tests  were  available  on  flights 
1-5  only.  When  a conflict  occurs,  guidance  maneuvers  and  guidance  phase  changes  take  priority 
over  test  maneuvers. 

The  flight  testing  has  been  planned  to  meet  program  objectives.  The  first  and  most  important 
is  to  open  the  eg  placards  as  quickly  as  possible  in  order  to  verify  the  safety  of  flying  planned 

payloads.  In  addition,  data  resulting  from  tests  are  scheduled  to  support  planned  flight  control 

system  changes  which  will  improve  control  where  in-flight  aerodynamic  anomalies  have  occurred. 

SENSOR  DATA  FOR  TESTING 

Sensor  data  used  in  stability  and  control  analysis  is  obtained  from  two  basic  sources.  The 
primary  source  of  data  is  the  aerodynamic  coefficient  identification  package  (ACIP),  which  is 
located  in  the  wing  carry-through  structure.  It  was  designed  specifically  for  aerodynamic  data 
extraction.  The  other  source  is  the  onboard  data  system,  which  provides  real-time  data  for  the 
guidance  and  flight  control  systems.  The  ACIP  is  a high  quality  data  package  recording  data  at 
173  samples  per  second  utilizing  a 14  bit  system.  The  onboard  data  system  records  data  at  5 and 
25  samples  per  second  using  an  8 bit  system.  A more  detailed  explanation  of  the  sensor  data  is 
given  in  reference  12. 


STABILITY  AND  CONTROL  MANEVUERS 

Maneuvers  for  stability  and  control  data  have  been  carefully  developed  to  provide  the  maximum 
amount  of  information  possible.  It  is  important  in  this  testing  to  excite  the  motion  defined  by 
the  derivatives  in  question,  so  as  to  identify  them  from  the  flight  data.  Because  of  the  limited 
testing  of  the  Shuttle  and  the  characteristics  of  the  flight  control  system,  precise  maneuver 
design  and  execution  are  very  important.  Poorly  performed  maneuvers  can  be  costly  to  the  program 
in  the  form  of  further  required  testing. 

The  flight  control  system  of  the  Shuttle  heavily  modifies  inputs  through  the  stick  and  is 
designed  to  damp  oscillations  and  transients.  This  design  causes  difficulty  in  pulsing  a control 
effector  |nd  allowing  motion  to  damp  as  is  done  with  most  aircraft.  In  pulsing  the  Shuttle,  the 
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control  system  modifies  the  stick  input  with  filters,  responds  to  rate  and  acceleration  feedback 
values,  and  damps  the  response  with  further  surface  motion.  In  general,  when  the  vehicle  is 
pulsed,  all  control  effectors  available  are  put  into  action  to  quickly  damp  the  vehicle  motion. 
This  can  cause  difficulty  in  separating  out  the  effectiveness  of  the  various  control  effectors. 

It  makes  it  difficult  to  accurately  identify  damping  derivatives. 

To  overcome  this  important  problem  and  to  provide  exact  designed  inputs,  programmed  test 
inputs  (PTI)  were  developed.  This  type  of  maneuver  is  input  directly  to  the  flight  control  system 
through  onboard  software.  The  amplitude  and  timing  is  governed  by  programmed  variables  to 
generate  a specific  input  at  a predesignated  flight  condition. 

The  crew  involvement  in  the  maneuvers  is  almost  entirely  a monitoring  function.  The  maneuver 
sequencing  is  initiated  by  the  crew  before  the  first  maneuver,  and  the  software  automatically 
executes  the  predefined  maneuvers  within  specified  windows.  These  windows  are  defined  by  dynamic 
pressure  or  Mach  number.  The  software  avoids  executing  maneuvers  close  to  bank  reversals  and 
other  guidance  phase  changes.  The  crew  monitors  trajectory  and  trim  parameters  and  important 
entry  flight  systems  to  assure  safe  maneuver  conditions.  The  crew  can  quickly  stop  the  maneuver 
sequence  by  moving  the  stick  or  selecting  the  control  stick  steering  (CSS)  mode.  They  have  full 
visibility  into  the  testing  status  through  items  on  their  displays. 

The  inputs  are  made  through  the  flight  control  system,  and  go  to  an  integrator  at  the  point 
where  the  surface  deflection  is  commanded.  The  input  is  added  to  the  current  command.  The 
command,  a surface  rate,  is  then  processed  through  a maximum  rate  limit  function.  Signals  can  be 
sent  to  the  elevon,  aileron,  rudder,  and  pitch,  yaw,  and  roll  jets.  Because  of  the  direct  input 
capability,  maneuvers  are  input  in  the  automatic  guidance  mode.  The  input  is  in  the  form  of  a 
doublet.  The  doublet  commands  surface  rate  in  one  direction  and  then  the  opposite  direction 
resulting  in  a pulse  from  the  control  effector.  These  doublets  can  be  strung  together  in 
combinations  to  provide  various  inputs  from  each  of  the  control  effectors.  There  is  a capability 
to  define  25  PTI  windows,  and  there  are  45  doublets  that  can  be  grouped  in  the  windows  as  desired. 

The  input  from  the  automatic  PTI  is  not  completely  free  of  flight  control  system 
interference,  but  the  design  does  allow  for  enhanced  maneuvers.  An  example  of  a maneuver  for  Mach 
5.8  is  illustrated  in  figure  14.  The  inputs  are  defined  by  amplitudes,  times,  and  the  effector  to 
be  pulsed.  The  flight  control  system  continues  to  respond  to  the  motion  feedback,  but  direct 
input  can  be  made  to  the  control  effector.  In  this  example  it  is  possible  to  make  the  aileron 
input  while  there  are  no  yaw  jet  firings. 

Direct  input  to  the  surfaces  in  a "bare  airframe"  sense  is  not  possible  in  the  program  at 
present.  With  the  basic  lack  of  stability  of  the  Shuttle,  it  would  not  be  safe  to  maneuver  the 
vehicle  without  an  active  control  system.  The  automatic  PTI  design  offers  the  most  feasible 
alternative  that  is  available. 

Maneuvers,  once  designed  for  the  optimum  motion  for  data  extraction,  are  assessed  for  flight 
control  and  guidance  safety.  Although  potential  problem  areas  are  approached  carefully,  care  must 
be  taken  in  maneuvering  not  to  excite  an  undamped  or  diverging  oscillation.  It  is  also  important 
not  to  perturb  the  trajectory  so  as  to  disturb  the  ranging  capability  during  the  Shuttle's  gliding 
descent. 

Maneuvers  are  studied  extensively  for  flight  control  safety.  Both  off-line  and  real-time 
simulators  are  used  to  study  maneuvers  with  worst  case  aerodynamic  uncertainty  combinations. 
Maneuver  amplitudes  are  increased  to  assess  safety  margins.  Loss  of  RCS  jets  is  also  simulated. 
Flight  test  aerodynamic  results  are  fed  through  this  same  process  to  verify  maneuver  safety 
margins  with  data  that  is  the  best  possible  representation  of  actual  Shuttle  characteristics. 

Maneuver  guidance  impacts  and  entry  timeline  conflicts  are  assessed  in  a similar  manner. 
Simulations  are  run  to  determine  conflicts  between  stability  and  control  maneuvers  and  guidance 
maneuvers  and  phase  changes.  Shuttle  pilots  assess  maneuver  conflicts  with  other  important  pilot 
functions.  If  conflicts  arise  from  these  studies,  maneuver  windows  are  adjusted  or  are  deleted. 

In  general  the  short,  low  amplitude,  PTI  maneuvers  have  a negligible  impact  on  guidance 
capability,  but  they  are  studied  nonetheless.  When  combined  with  other  maneuver  sequences, 
guidance  impacts  can  occur.  RCS  jet  fuel  budgets  for  maneuvers  are  developed  during  these 
simulations  to  provide  the  pilots  with  fuel  "red  lines"  that  must  not  be  violated,  in  order  to 
continue  initiating  maneuvers.  Usage  of  RCS  fuel  during  maneuvers  is  significant.  Loss  of 
vehicle  control  is  possible  if  the  RCS  fuel  is  depleted. 
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SHUTTLE  MANEUVER  TEST  PLAN 


The  maneuvers  planned  or  already  flown  on  each  flight  are  listed  in  figure  15.  The  left  hand 
column  lists  the  flight  conditions  at  which  the  tests  are  planned.  The  other  columns  are  labeled 
by  flight  number.  Flight  one  had  no  planned  maneuvers  other  than  bank  reversals  required  for 
ranging.  The  first  entry  was  designed  to  be  as  benign  as  possible.  Flight  2 had  25  maneuvers, 
including  pitch  and  roll  maneuvers  for  stability  and  control  data,  a pushover  pullup  maneuver,  and 
bodyflap  pulses.  Subsequent  to  STS-2,  decisions  were  made  to  reduce  the  number  of  maneuvers  per 
flight  so  as  to  decrease  crew  workload  during  entry.  As  a result  fewer  maneuvers  are  shown  on 
flights  3-17.  The  test  program  has  therefore  evolved  from  an  initial  10  flights  into  a 17  flight 
program  in  order  to  obtain  sufficient  data.  It  can  be  observed  in  figure  15  that  the  most 
concentrated  testing  is  from  Mach  6 to  .9.  This  is  because  it  is  the  most  critical  regime  with 
respect  to  potential  problems  in  stability  and  control. 

The  test  plan  for  stability  and  control  data  is  designed  to  provide  sufficient  information  to 
remove  forward  and  aft  eg  constraints.  The  forward  center  of  gravity  travel  is  limited  primarily 
by  aileron  characteristics  at  negative  elevon  settings.  To  verify  the  aileron  characteristics 
before  flying  a forward  eg,  the  vehicle  trim  of  a forward  eg  is  simulated  by  appropriate 
scheduling  of  the  elevon.  Elevon  schedules  for  flights  1-17  are  shown  in  figure  16  with  the 
locations  of  the  maneuvers  from  figure  15  superimposed.  The  schedules  cover  the  range  of  expected 
values  for  the  full  range  of  cgs.  These  elevon  schedules  are  attained  during  flight  by  onboard 
software  programming  of  the  elevon  settings.  The  bodyflap  is  used  to  trim  the  vehicle  at  the 
given  setting.  The  schedule  shown  for  flight  2 is  the  most  benign  schedule  and  provides  the  most 
positive  aileron  control  between  Mach  6 to  1 . As  the  flights  progress  and  more  data  is  obtained, 
the  elevons  are  to  be  scheduled  gradually  more  up  (-)  until  the  most  forward  eg  is  simulated  on 
flights  14-17.  Hypersonically , the  elevon  is  being  trimmed  beyond  what  is  required  during  normal 
entry  for  a forward  eg  (figure  13).  This  is  due  to  the  data  already  obtained  which  indicated 
anomalous  aileron  effectiveness  as  a function  of  elevon  position.  The  settings  shown  on  flights 
14  to  17  should  shed  additional  light  on  this  problem  and  the  results  can  be  used  to  assess 
certain  abort  profiles  which  use  more  negative  elevon  positions  for  trim. 

Angle  of  attack  will  be  varied  on  a limited  number  of  flights.  Figure  17  illustrates  the 
nominal  angle  of  attack  profiles  to  be  flown  on  particular  flights.  Maneuvers  will  be  executed 
along  these  profiles  to  verify  predicted  angle  of  attack  trends  in  stability  and  control 
parameters.  Flights  6,  8,  and  12  will  be  flown  with  an  elevon  schedule  that  has  been  flown 
previously  so  as  to  vary  only  one  parameter  at  a time.  Flights  14,  16,  and  17  will  be  flown  with 
an  elevon  setting  that  represents  the  trim  requirements  for  a forward  eg.  The  symbols  represent 
where  maneuvers  will  occur  along  the  profile  on  flights  where  the  profile  is  off-nominal. 

Stability  derivatives  C0  and  C are  of  particular  interest  as  a function  of  angle  of  attack. 

« \ 

In  addition,  an  understanding  of  the  possibility  of  aileron  effectiveness  being  a function  of  the 

combined  effects  of  angle  of  attack  and  elevon  is  to  be  studied.  This  will  require  deviations  in 
both  angle  of  attack  and  elevon  position  for  various  maneuver  test  points. 

Additional  factors  in  the  planning  will  contribute  to  the  necessary  understanding  of  the 
stability  and  control  characteristics  of  the  Shuttle.  Figure  18  shows  speedbrake  schedules  for 
the  nominal  entry,  and  planned  schedules  for  flights  5 through  17.  With  these  different 
schedules,  rudder  sensitivities  can  be  obtained.  With  the  automatic  maneuvers  beginning  on  flight 
5,  a rudder  pulse  can  be  input  at  any  point  regardless  of  whether  or  not  the  rudder  is  active  in 
the  flight  control  system.  The  rudder  normally  becomes  active  at  Mach  3.5.  With  this  capability, 
the  rudder  effectiveness  will  be  tested  1/2  Mach  number  higher  per  flight,  beginning  on  flight  5 
at  Mach  4.  To  obtain  further  data  on  possible  aerodynamic  asymmetric  characteristics  of  the 
Shuttle,  Ycg  offsets  are  planned  through  payload  placement.  Ycg  values  of  .5  to  .9  inches  have 
been  flown  on  flights  4 and  5.  A Ycg  value  of  1.5  inches  is  planned  for  flights  7 and  11,  with 
the  sign  of  the  offset  reversing  between  the  two  flights.  Although  POPU  maneuvers  were  planned 
primarily  to  obtain  aerodynamic  performance  and  aerothermal  data,  these  maneuvers  were  also  a 
valuable  source  of  additional  longitudinal  stability  and  control  data.  Bodyflap  pulses  were  flown 
only  on  STS-2.  During  these  maneuvers  the  crew  manually  changed  bodyflap  trim  down  (+)  to  move 
the  elevons  up  (-).  A PTI  was  then  performed.  This  was  to  provide  early  indications  of  aileron 
effectiveness  with  more  (-)  elevon  settings. 


FLIGHT  DATA  ASSESSMENTS 


An  important  product  of  the  flight  test  program  is  the  confidence  that  is  gained  from  flight 
test  results,  in  assessing  the  safety  of  upcoming  flights.  Vehicle  cgs  associated  with  specific 
payloads  must  be  shown  to  be  safe.  In  addition,  further  testing  in  the  flight  test  program 
depends  on  values  of  derivatives  obtained  from  previous  tests.  For  instance,  it  is  important  to 


274 


understand  as  much  as  possible  about  stability  and  control  characteristics  for  down  elevon 
positions,  before  it  is  safe  to  fly  with  elevons  at  more  negative  settings.  To  accomplish  this, 
fairings  are  developed  for  the  flight  test  results  and  are  provided  to  the  Shuttle  flight  control 
system  community.  These  fairings  or  "assessment"  values  are  incorporated  into  simulators  which 
are  used  to  verify  the  safety  of  upcoming  flights.  Exact  maneuvers  and  trajectory  profiles  are 
simulated  with  correct  cgs.  In  addition,  stability  analyses  are  performed  using  the  flight 
derived  aerodynamic  data  to  update  eg  placards  for  the  vehicle. 


STS-1  THRU  -4  FLIGHT  ASSESSMENT  VALUES 


Flight  test  results  in  the  form  of  stability  and  control  derivatives  have  been  output  for  use 
in  simulators  after  flights  1,  2,  and  4.  Some  of  the  most  significant  of  these  derivatives  are 
shown  in  figures  19  to  24.  These  figures  show  derivative  values  for  various  types  of  maneuvers 
from  flights  1 to  4.  It  is  important  to  note  that  the  highest  quality  maneuvers  are  the  PTI's, 
which  have  darkened  symbols.  In  the  plots,  pre-flight  1 Aerodynamic  Design  Data  Book  values 
(solid  line)  and  the  associated  uncertainties  are  drawn.  The  abrupt  changes  in  the  data  book 
values  at  some  locations  are  due  to  the  data  being  plotted  for  the  specific  flight  condition  and 
configuration  where  the  maneuver  was  executed  and  do  not  represent  abrupt  nonlinearities  in  the 
data  base.  The  uncertainty  brackets  on  the  derivatives  are  Cramer  Rao  bounds,  which  provide 
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information  on  the  relative  accuracy  of  data  extraction  between  data  points.  Also  drawn  on  the 
plots  are  the  STS-4  assessment  values.  These  assessment  values  are  the  fairings  that  have  been 
published  from  flights  1 to  4 for  these  derivatives. 


For  C0  in  figure  19,  the  flight  test  values  are  shown  to  be  significantly  more  positive  than 

what  was  predicted  above  Mach  10.  However,  this  is  of  no  particular  concern  to  the  safety  of  the 
Shuttle  through  this  Mach  regime.  Below  Mach  6 the  C«  fairing  is  shown  to  be  approximately 

P 

halfway  between  nominal  and  the  lower  value  of  the  uncertainties.  This  value  of  C , by  itself  is 
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not  of  concern  for  for  Shuttle  safety  of  flight,  but  if  C should  become  positive  for  more  up 
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elevon  settings,  the  more  negative  C0  will  have  an  adverse  effect  on  the  LCDP. 

p 


Aileron  effectiveness  above  Mach  10  is  shown  for  PTI's  in  figures  20  and  21.  These  values 
are  plotted  as  a function  of  elevon  position.  Because  of  the  spread  of  elevon  between  flights  1 
through  4 in  this  Mach  regime,  a difference  in  the  effect  of  elevon  on  aileron  effect ivness  has 


been  discovered.  Both  C0 


and  C 


indicate  increased  effectiveness  with  down  elevon 


deflections.  The  assessment  values  for  elevon  settings  above  0°  were  set  to  nominal,  because  of 
the  lack  of  data.  If  the  trend  for  positive  elevon  deflections  extend  to  negative  elevon 
deflections,  the  aileron  may  be  less  effective  than  predicted.  Although  this  difference  between 
predicted  and  actual  aileron  effectiveness  has  little  effect  on  safety  hypersonically , the  impact 
to  eg  placards  could  be  important  if  the  trend  continues  at  lower  Mach  numbers.  Testing  on  later 
flights,  where  the  elevon  will  be  scheduled  with  more  negative  settings,  will  provide  the 
necessary  data  to  determine  Shuttle  eg  impacts.  This  example  points  out  the  importance  of 
obtaining  derivative  sensitivities  to  elevon  and  angle  of  attack  profiles.  Between  Mach  2 and  1 
(figure  22)  the  flight  values  of  roll  due  to  aileron  are  shown  to  be  less  effective  than 

predicted.  In  this  region  the  elevon  has  been  above  0°  deflection  due  to  overshooting  the  elevon 
schedule.  Because  there  has  been  no  spread  in  the  elevon  deflections  on  flights  1 to  4,  it  is  not 
yet  possible  to  attribute  this  anomaly  to  effectivness  due  to  elevon  position.  Later  flights  will 
provide  the  spread  necessary  to  determine  this  function. 


The  most  significant  updates  in  stability  and  control  aerodynamics  are  the  assessment  values 
and  new  uncertainties  for  yaw  jet  effectiveness.  Figures  23  and  24  show  very  consistent  flight 
test  results  for  RCS  yaw  jet  effectiveness.  After  STS-4  sufficient  data  was  available  to  update 
nominal  values  and  reduce  RCS  jet  ef fectiveness  uncertainties  from  early  entry  through  Mach  1, 
where  the  yaw  jets  are  turned  off.  The  jets  were  shown  to  be  more  effective  than  predicted. 

These  results  have  had  a significant  effect  on  eg  expansion. 


CENTER  OF  GRAVITY  EXPANSION 

The  primary  goal  of  the  entire  data  extraction  effort  is  to  open  eg  placards  for  the  Shuttle, 
so  that  the  full  payload  carrying  capability  can  be  utilized.  Through  the  planned  maneuvers,  and 
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elevon  and  angle  of  attack  schedules,  sufficient  data  is  to  be  obtained  to  verify  the  Shuttle 
operational  safety  during  entry.  The  operational  limits  for  eg  have  been  specified  to  be  from  65 
to  67.5  percent  of  the  reference  body  length.  This  represents  a eg  travel  of  32.32  inches.  It  is 
the  goal  of  the  test  program  to  relax  eg  placards  to  these  operational  limits.  Figure  25  shows 
the  expansion  of  the  Xcg  that  has  taken  place  as  a result  of  flight  test  data  from  STS-1  thru  -4. 
Opening  of  the  aft  eg  boundary  as  well  as  initial  opening  of  the  forward  boundary  is  primarily  a 
result  of  the  confidence  that  has  been  gained  in  the  knowledge  of  the  basic  pitching  moment  of  the 
vehicle.  Pitch  jet  trim  requirements  were  also  determined.  The  most  restrictive  boundary  is  the 
forward  eg  limit,  because  of  the  critical  potential  problem  areas  between  Mach  6 and  1.  The  most 
significant  relaxation  of  this  forward  boundary  occurred  because  of  the  yaw  jet  flight  test 
results.  The  more  effective  jets  along  with  the  reduced  uncertainties  resulted  in  the  change 
shown  in  the  placard  between  STS-5  and  -6.  This  has  proved  the  safety  of  flying  payloads  planned 
for  STS-7  and  -9.  Also  shown  in  figure  25  are  aft  eg  flight  test  limits,  which  must  be  honored  in 
order  to  fly  the  elevon  schedules  planned  for  these  flights.  Relaxation  of  the  boundary  to  the 
full  forward  limit  of  65  percent  body  length  will  occur  as  a result  of  decreases  in  other 
stability  and  control  derivative  uncertainties  by  the  end  of  the  flight  test  program. 
Optimistically  these  data  will  prove  that  predicted  potential  control  problems  do  not  exist. 


CONCLUSIONS 


The  successful  flight  of  STS-1  in  April  1981  proved  that  the  challenge  of  the  FCS  design  and 
verification  has  been  met.  The  flight  test  data  so  far  is  indicating  that  the  aerodynamic 
variations  were  not  overly  conservative,  but  are  representative  of  the  actual  differences 
experienced  in  most  of  the  aerodynamic  coefficients  at  some  point  during  reentry.  The  successful 
extraction  of  flight  test  data  from  the  first  four  flights  is  proving  that  the  challenge  of 
developing  an  operational  vehicle  with  a minimum  flight  test  program  is  being  successfully  met. 

The  placards  on  the  orbiter  during  entry  are  to  be  reduced  after  17  flights  based  on  high 
quality  data  from  carefully  designed  manevuers.  The  approach  is  optimistic  and  ambitious  but 
every  effort  is  being  made  to  insure  its  success  through  careful  maneuver  design,  quality  data  and 
safety  analysis.  The  experience  gained  and  techniques  employed  in  the  Shuttle  program  are 
applicable  to  future  flight  test  planning  in  programs  where  testing  must  be  limited  due  to  time 
constraints  or  expense. 
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TABLE  1 ORBITER  CORRELATION  APPLICABILITY  (REFERENCE  2) 


GEOMETRIC  FACTORS 

REMARKS 

AIRCRAFT* 

A WING  WING  SINGLE  LARGE 

WING  FLAP  ELEVON  VERTICAL  FUSLAGE 

PLANFORM  LONG.  LATERAL  TAIL 

CONTROL  CONTROL 

XB-70 

¥ ¥ ¥ 

GOOD  PRED  BASE, 
M RANGE, CANARD, 
LIMITED  a RANGE 

YF-12 

^ V V 

GOOD  M RANGE, 
LIMITED  a RANGE 

X-15 

¥ ¥ 

WIDE  a,  M RANGE 

TACT  A = 58° 

^ V V 

ONLY  LIMITED  DATA 

CURRENTLY 

AVAILABLE 

HP115 

¥ ¥ ¥ ¥ 

LOW  SPEED  DATA 
ONLY 

B-58 

¥ ¥ ¥ ¥ 

GOOD  PREDICTIVE 
BASE,  M RANGE 

YF-16 

F-8SCW 

¥ 

SOURCE  OF  RUDDER 
CONTROL  DATA 

*SEE  REFERENCE  2 FOR  AIRCRAFT  IDENTIFICATION 
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ROLLING  MOMENT  COEFFICIENT 


YAWING  MOMENT  COEFFICIENT  - Cn 
Figure  1.  ELLIPTICALLY  CORRELATED  VARIATIONS 


MACH  3 50 
ALPHA  1500 


YAWING  MOMENT  COEFFICIENT  - C„ 


AERODYNAMIC  VECTORS  AT  MACH  3.5  SHOWING  VARIATION  SETS 

Figure  2.  AERODYNAMIC  VECTORS  AT  MACH  3.5  SHOWING  VARIATION  SETS 
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ELEVON  TRIM  POSITION.  DEGREE 


ANGLE  OF  ATTACK.  DEG 

Figure  3.  EFFECT  OF  ANGLE  OF  ATTACK  ON 
LCDP  FOR  AERO  VARIATION  SET  19 


Figure  4.  ELEVON  TRIM  ENVELOPE  FOR  DESIGN  C.G.  LIMITS 
WITH  PITCHING  MOMENT  VARIATIONS 
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ELEVON  TRIM  POSITION,  DEG 


66.7  PERCENT  X c.g. 


MACH  NUMBER 

Figure  5.  ELEVON  TRIM  ENVELOPE  FOR  66.7  PERCENT  LB  X c.g. 
WITH  PITCHING  MOMENT  VARIATIONS. 


65.0  66.0  67.0 

X CG  LOCATION.  PERCENT  BODY  LENGTH 

Figure  6.  EFFECT  OF  CG,ANGLE  OF  ATTACK 
ON  LCDP  AT  MACH  3.5  WITH  AERO  VARIATIONS  SET  19 
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DYNAMIC.  PER  DEGREE 


66.5  66.75  67.0  67.25 

X CG  PERCENT  BODY  LENGTH 

Figure  7.  RECOMMENDED  CG  ENVELOPE  CONTAINED 
IN  FLIGHT  RULES  DOCUMENT  FOR  STS-1 


Figure  8.  Cn  DYNAMIC  FOR  WORST  CASE  VARIATION  SET 
13  1 g FLIGHT  AT  7.5  DEGREES  ALPHA 
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I 


MACH  NO. 


Figure  9.  LOWER  ANGLE  OF  ATTACK  BOUNDARY 
CONTAINED  IN  FLIGHT  RULES  DOCUMENT  FOR 
EARLY  ORBITER  FLIGHTS 


DA  OCKOM  AIM  t MAC  NT 


Figure  10.  ENTRY  VERIFICATION  TEST  MATRIX 


(DESIGN) 


Figure  11.  GN&C/FCS  FORMAL  VERIFICATION  PROCESS 
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ANGLE  OF  ATTACK(DEG) 


PREFLIGHT  TEST  REQUIREMENTS 
AND  FLIGHT  ANOMALIES 


PRE-FLIGHT  CONCERNS  AT  C.G.  EXTREMES 

A.  VISCOUS  TRIM  AND  LONGITUDINAL  CONTROL 
(RCS  FUEL, TRIM  AUTHORITY) 

B.  LAT/DIR  TRIM  WITH  ADVERSE  cn  (EXCESSIVE 
RCS  FUEL, TRIM  AUTHORITY)  8a 

C.  LAT/DIR  TRIM,  CONTROL  AUTHORITY  WITH 
UNCERTAIN  AILERON,  RUDDER,  JETS 

D.  LAT/DIR  CONTROL  AUTHORITY  WITH 
UNCERTAIN  AILERON,  RUDDER  JETS 

E.  LOSS  OF  RUDDER  EFFECTIVENESS  AND 

LAT  STABILITY  AT  LOW  SPEED  BRAKE  SETTINGS 


4°  OSCILLATION  AT  1ST  BANK 

A.  ROLL  DUE  TO  YAW  JET 

B.  AILERON  EFFECTIVENESS 

2.  TOTALCm  OUTSIDE  VARIATIONS  (BODY  FLAP  TRIM) 

3.  LATERAL  TRIM  OFFSETS  (6a) 

4.  AILERON  EFFECTIVENESS  AS  A FUNCTION  OF  ELEVON 
POSITION  NOT  AS  PRECICTED  (Cy^,  C ^ g ,Cn<5  ) 

5.  SUPERSONIC  ANOMALIES 
A-  Cj0  5a  LOW,  MACH  3-1 

B.  MACH  2-1  OSCILLATIONS  (C^  5|,) 

6.  BODY  FLAP  SATURATES  UP 
MACH  24-1, Cn«  HIGH  BY  VARIATIONS 


10  12  14  16  18  20  22  24  26 


MACH 


Figure  1 2 
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ELEVON  TRIM  CAPABILITY 


Figure  13 


AUTOMATIC  PTI  CAPABILITY 

A1-62.5 
A2  = 10 

YAW  JET 

INPUT  TIME  (SEC)  I LOAD 


Figure  14 
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MANEUVER  TEST  PLAN 
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Figure  15 
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FLIGHT  TEST  ELEVON  PROFILES 


l>0 

00 

VO 


Figure16 


FLIGHT  TEST  ANGLE  OF  ATTACK  PROFILES 


MACH  q (PSF) 

Figure  17 


SPEEDBRAKE  SCHEDULE  FOR  TESTING 


Figure  18 
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Figure  19 


CK  AS  A FUNCTION  OF  ELEVON  POSITION  FOR  M > 10,  STS  1-4 
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Cn<5aAS  A FUNCTION  OF  ELEVON  POSITION  FOR  M > 10,  STS  1-4 


Figure  21 


Figure  22 


292 


NJET  (PER  JET) 


LJET  (PER  JET)  0 


ROLLING  MOMENT  DUE  TO  YAW  JETS, 

STS  1-4 

✓ \ lv  ^ \ . 

/ <v  % A 


— — STS-4  ASSESSMENT 

PROPOSED  UNCERTAINTY 

UPDATED  UNCERTAINTY 

A ENTER  BANK  REVERSAL 
V EXIT  BANK  REVERSAL 
■ PROGRAMMED  TEST  INPUT  (PTI) 
O OTHER 
ADDB® 


MACH 

Figure  24 
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SHUTTLE  CENTER  OF  GRAVITY  PLACARDS  (M  = 3.5) 
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ABSTRACT 


The  Approach  and  Landing  Test  (ALT)  of  the  Space  Shuttle  Orbiter  presented  a number  of  unique 
challenges  in  the  area  of  aerodynamics.  The  purpose  of  the  ALT  program  was  both  to  confirm  the  use 
of  the  Boeing  747  as  a transport  vehicle  for  ferrying  the  Orbiter  across  the  country  and  to 
demonstrate  the  flight  characteristics  of  the  Orbiter  in  its  approach  and  landing  phase.  Concerns 
for  structural  fatigue  and  performance  dictated  a tailcone  be  attached  to  the  Orbiter  for  ferry  and 
for  the  initial  landing  tests.  The  Orbiter  with  a tailcone  attached  presented  additional 
challenges  to  the  normal  aft  sting  concept  of  wind  tunnel  testing.  The  landing  tests  required  that 
the  Orbiter  be  separated  from  the  747  at  approximately  20,000  feet  using  aerodynamic  forces  to  fly 
the  vehicles  apart.  This  concept  required  a complex  test  program  to  determine  the  relative  effects 
of  the  two  vehicles  on  each  other.  Also  of  concern,  and  tested,  was  the  vortex  wake  created  by  the 
747  and  the  means  for  the  Orbiter  to  avoid  it  following  separation. 


NOMENCLATURE 


c Mean  aerodynamic  chord 

eg  Center  of  gravity 

Cp  Drag  coefficient 

C^  Lift  coefficient 

FF  Free  flight 

hw  Main  landing  gear  wheel  height  above  ground 

IML  Interface  mold  line 

LE  Leading  edge 

L/D  Lift-to-drag  ratio 

M Mach  number 

MAC  Mean  aerodynamic  chord 

q Dynamic  pressure 

Xq , Yq ,Zq  Orbiter  vehicle  body  coordinate  system 

a Angle  of  attack,  degrees 

6gp  Body  flap  deflection,  degrees 

6^  Speedbrake  deflection,  degrees 


INTRODUCTION 

When  the  Space  Shuttle  design  was  begun,  in  1969,  the  concept  included  aircraft  type  jet  engines  on 
the  Orbiter  vehicle.  The  engines  would  have  provided  a more  flexible  landing  operation  and  a means 
to  ferry  the  vehicle  from  manufacturing  or  landing  sites  to  the  launch  site.  This  design  concept 
proved  not  to  be  feasible  for  a number  of  reasons.  While  the  need  to  have  engines  for  landing  was 
overcome,  the  need  to  ferry  the  Orbiter  across  the  country  still  existed.  Further,  most  felt  that 
the  Orbiter  approach  and  landing  phase  needed  checkout  prior  to  the  first  entry  from  orbit. 
Alternate  solutions  involved  the  use  of  strap-on  engines  to  the  wings  and  a plan  to  put  a kit, 
containing  both  fuel  and  engines,  in  the  payload  bay.  Neither  was  considered  a viable  concept. 

At  this  point,  NASA  really  had  built  a "boat  in  the  basement".  Not  only  could  the  approach  and 
landing  phase  not  be  tested,  but  transporting  the  Orbiter  from  the  manufacturing  site  at  Palmdale, 
California  to  the  Kennedy  Space  Center  in  Florida  had  no  practical  solution. 

It  was  then  suggested  by  John  W.  Kiker  of  the  Johnson  Space  Center  (JSC)  in  Houston,  that  the 
Orbiter  be  ferried  by  another  vehicle  in  a mode  similar  to  that  used  to  launch  the  X-15  aircraft. 
Consideration  was  given  to  existing  aircraft;  ie.,  the  Lockheed  C5A‘and  the  Boeing  747,  as  well  as 
to  developing  a new  airplane  for  that  explicit  purpose.  Configurations  were  considered  with  the 
Orbiter  positioned  atop  and  also  below  the  carrier  aircraft.  Trade  studies  were  performed  which 
indicated  that  it  was  feasible  to  carry  the  Orbiter  aboard  an  aircraft  in  a piggyback  fashion.  It 
was  also  believed  possible  to  launch  the  Orbiter  from  such  a position  in  order  to  do  an  Approach 
and  Landing  Test  (ALT),  and  the  Boeing  747  was  selected  as  the  carrier  aircraft. 
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The  solution  also  produced  new  problems.  The  blunt  aft  section  of  the  Orbiter  would  produce 
considerable  drag  and  create  disturbances  which  could  cause  fatigue  to  the  vertical  tail  of  the 
carrier.  Thus,  for  ferry  purposes,  it  was  concluded  that  an  aft  fairing  would  be  required  on  the 
Orbiter.  One  of  the  first  considerations  was  the  design  of  the  fairing,  or  tailcone. 

Also  of  concern  was  the  performance  of  the  mated  vehicle,  both  from  a range  stand  point  for  ferry 
and  from  altitude  and  relative  aerodynamics  for  separation.  The  primary  emphasis  was  on  the 
relative  attitude  of  the  two  vehicles  to  obtain  an  optimum  configuration  for  both  ferry  flight  and 
separation.  Restrictions  included  the  Orbiter  attach  points,  clearance  of  the  tailcone,  and  loads 
on  the  carrier  aircraft. 

The  need  to  perform  an  aerodynamic  separation  between  two  maneuverable  vehicles  required 
considerable  aerodynamic  testing  and  analysis.  Again,  other  variables,  originally  unsuspected, 
arose.  One  example  was  the  concern  for  the  vortex  wake  produced  by  the  carrier  and  the  possibility 
of  upsetting  the  Orbiter  if  it  encountered  the  vortex  wake  following  separation. 

The  Orbiter' s subsonic  aerodynamic  characteristics  required  early  testing  and  definition  to  allow 
for  design  of  the  complex  flight  control  system.  Further  complicating  the  situation  was  the  desire 
to  also  fly  the  Orbiter  with  a tailcone  attached  for  the  first  landing.  With  the  tailcone,  the 
Orbiter  lift-to-drag  ratio  was  significantly  improved,  and  it  was  felt  that  the  other  Orbiter 
systems  could  be  tested  with  less  risk  if  the  initial  flights  were  performed  with  the  tailcone 
attached.  Thus,  the  aerodynami cists  were  required  to  develop  a data  base  for  not  only  a basic 
flight  Orbiter,  but  also  an  Orbiter  with  a tailcone  attached.  Similarly,  the  separation  testing 
had  to  be  done  with  both  configurations. 

The  testing  required  to  select  a mated  configuration  and  to  obtain  the  separation  aerodynamics  are 
covered,  as  is  the  testing  of  the  vortex  wake  created  by  the  carrier.  The  problems  associated  with 
wind  tunnel  testing  the  Orbiter,  with  the  tailcone  attached,  are  discussed.  Comparisons  of  flight 
test  and  wind  tunnel -derived  predicted  aerodynamics  are  described  with  particular  emphasis  on 
performance,  ground  effects,  and  landing  gear  effects  for  the  Orbiter,  with  and  without  the 
tailcone  attached. 


THE  EVOLUTION  OF  THE  ALT  PROGRAM 

The  initial  design  of  the  Orbiter  included  jet  engines  to  enable  the  Orbiter  to  land  like  a 
conventional  aircraft.  In  the  usual  NASA  manner  of  redundancy,  it  was  felt  that  the  Orbiter  should 
be  able  to  land  safely  even  if  the  jet  engines  could  not  be  started;ie,  if  powered  flight  were  the 
nominal  mode  for  the  final  landing  phase,  the  Orbiter  must  be  designed  to  fly  unpowered  for 
contingency  situations.  The  cost  of  the  engines  was  a considerable  factor.  In  addition  to  the 
added  weight  penalty  for  the  engines  themselves,  there  were  structural  weight  penalties  for 
designing  the  wing  to  carry  the  engines.  There  were  cost  risks  because  of  the  technical  unknowns 
of  the  environmental  effects  on  the  engines  - the  launch  loads  and  heating,  the  extreme  temperature 
environment  on-orbit,  and  the  effects  of  entry  heating  and  accelerations.  These  concerns,  and  the 
requirement  to  design  for  an  unpowered  landing,  led  to  the  design  modification  to  build  an 
unpowered  Orbiter. 

This  decision  to  design  an  unpowered  Orbiter,  for  the  Space  Shuttle  launch  and  entry  configuration, 
affected  two  other  areas.  First,  the  need  still  existed  to  ferry  the  Orbiter  between  sites  - 
manufacturing  and  landing  sites  to  launch  sites.  When  the  Orbiter  was  conceived  as  a powered 
flight  vehicle,  it  could  have  transported  itself  between  sites.  With  the  decision  not  to 
incorporate  engines,  the  ferry  technique  was  unresolved.  Secondly,  there  was  a plan  to  flight  test 
the  Orbiter  in  its  subsonic  regime.  There  were  no  unmanned  flights  in  the  program,  and  to  have  the 
first  landing  be  that  of  the  Orbiter  from  an  entry  point  seemed  an  extreme  option. 

Consideration  was  given  to  engines  which  could  be  attached/removed  for  the  purposes  of  ferry  and 
subsonic  testing.  The  cost  and  complexity  of  this  system  caused  it  to  be  rejected.  Further,  the 
design  optimization,  for  the  unpowered  landing  characteristics,  resulted  in  an  airplane  which  was 
not  designed  for  takeoff. 

It  was  at  this  time  that  the  carrier  aircraft  concept  was  proposed.  A multitude  of  ideas  were 
evaluated.  The  extension  of  a large  aircraft's  landing  gear,  necessary  to  carry  the  Orbiter  in  an 
X-15  fashion  seemed  unreasonably  complex.  The  idea  of  developing  a new  carrier,  with  the  single 
purpose  of  carrying  the  Orbiter,  was  unreasonably  costly.  The  options  were  reduced  to  carrying  the 
Orbiter  piggyback  on  either  a Boeing  747  or  a Lockheed  C-5A.  The  technical  concerns  with  both 
vehicles  were  related  to  clearances  of  the  carrier  vertical  tail  and  relative  aerodynamic  effects 
during  separation.  The  T-tail  on  the  C-5A  presented  additional  complications  over  the  Boeing  747 
aircraft.  Of  particular  concern  was  the  effect  of  the  Orbiter  wake  on  the  C5A  T-tail  immediately 
following  separation. 
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The  actual  decision  to  fly  the  Boeing  747  was  based  more  on  logistics  than  on  technical  rationale. 
The  only  C-5A  available  would  have  been  loaned  to  NASA  by  the  Air  Force.  Since  the  Air  Force  could 
recall  the  plane  at  any  time,  NASA  would  not  be  able  to  schedule  operations  without  risk. 

During  the  feasibility  assessment,  it  was  found  that  the  Orbiter's  blunt  aft  end  (see  Figure  1) 
would  severely  affect  Orbiter/carrier  performance  both  for  climb  and  for  ferry  range.  Further,  it 
was  believed  that  the  carrier  vertical  tail  would  suffer  structural  fatigue  due  to  the  flow  behind 
the  Orbiter.  Therefore,  a drag  reducing  attach  structure,  a tailcone,  was  proposed  (see  Figure  2). 
This  structure  was  to  both  reduce  drag  for  performance  improvements  and  to  lessen  the  fatigue 
factor.  Because  the  extent  of  these  problems  was  not  known,  plans  to  flight  test  the  Orbiter  in 
its  final  landing  phase  also  included  retaining  the  tailcone. 

At  the  time  that  the  Orbiter/carrier  aircraft  program  development  was  initiated,  it  was  thought 
that  nothing  of  this  type  had  been  attempted  previously.  It  was  as  a great  surprise  to  learn  that 
the  Europeans  had  flown  piggyback  configurations,  even  before  World  War  II.  The  English,  French 
and  Germans  each  had  some  type  of  flight  system  which  utilized  two  aircraft,  one  attached  to  the 
back  of  the  other.  The  English  had  used  their  aircraft  on  mail  runs  to  Greenland  prior  to  World 
War  II.  The  French,  who  had  begun  their  program  before  the  war,  hid  their  airplanes  until  after 
the  war.  Films  of  the  flight  of  the  French  configuration  were  made  available  to  NASA.  Of  interest 
was  the  relative  incidence  angle,  the  attach  structure  and  the  pitchover  maneuver  to  achieve 
separation.  All  were  very  similar  to  the  design  selected  for  the  ALT  program.  Whether  any  wind 
tunnel  testing  was  ever  performed  on  these  European  airplanes  is  not  known. 


ORBITER/SHUTTLE  CARRIER  AIRCRAFT  WIND  TUNNEL  TEST  PROGRAM 


The  decision  to  fly  an  Orbiter/Shuttle  Carrier  Aircraft  (SCA)  configuration  required  that  the 
precise  configuration  be  established  in  a relatively  short  period  of  time.  Following  the  selection 
of  the  Boeing  747  as  the  SCA,  the  initial  wind  tunnel  tests  were  designed  to  gather  data  on 
proposed  configurations  to  optimize  the  Orbiter/SCA  with  respect  to  both  climb  and  separation 
performance.  A number  of  drag-reducing  attach  structure  fairings  were  assessed  to  select  the 
tailcone  configuration.  The  testing  involved  the  Orbiter,  with  and  without  a tailcone,  and  a wide 
range  of  Orbiter  incidence  angles  and  elevon  deflections.  Two  model  scales,  three  facilities,  and 
a range  of  Mach  numbers  and  Reynolds  numbers  were  tested  to  provide  a means  for  correlating  and 
abbreviating  future  tests  throughout  the  program.  The  information  gained  from  this  series  of  tests 
led  to  the  establishment  of  a mated  configuration  data  base.  One  modification  was  made  to  the  SCA, 
the  addition  of  vertical  stabilizers  on  the  tips  of  the  horizontal  tail,  to  compensate  for  the  loss 
of  stability  with  the  Orbiter  blanketing  the  vertical  tail. 

A test  was  then  conducted  which  provided  performance,  stability,  and  control  data  for  the  mated 
vehicle  in  the  launch  configuration.  That  same  test  was  used  to  gather  Isolated  SCA  data  and 
proximity  data  for  each  vehicle  at  the  Instant  of  separation  by  equipping  each  model  with  a 
balance.  The  SCA  balance  also  read  total  vehicle  data  when  the  Orbiter  was  attached.  Only  the 
Orbiter  with  tailcone  attached  was  used  for  this  test,  because  at  this  time  no  tailcone-off  flights 
were  being  considered.  Deflections  of  the  Orbiter  elevon  and  body  flap  and  the  SCA  stabilizer  were 
evaluated  for  their  effects  on  the  proximity  data.  From  this  test  came  the  data  to  establish  the 
initial  target  conditions  for  separation  and  the  performance  estimates  for  the  ferry  flights. 

A verification  test  was  conducted  on  the  Orbiter/SCA  configuration  using  the  same  model  as  the  test 
used  to  establish  the  data  base,  but  a different  facility.  Runs  were  replicated  from  the  earlier 
test  to  establish  confidence  in  the  data.  The  Orbiter,  without  the  tailcone,  was  at  this  time 
incorporated  into  the  testing,  since  the  ALT  program  had  been  modified  to  include  flight  tests  with 
the  flight  type  Orbiter;ie,  without  tailcone.  Data  from  these  tests  can  be  found  in  Ref.  1. 


SEPARATION  WIND  TUNNEL  TEST  PROGRAM 

The  technical  community  expressed  calm  assurance  that  a mated  flight  program  was  a feasible 
undertaking.  The  separation  of  two  vehicles  in  flight  did  not  produce  the  same  response.  Some  of 
the  community  had  experienced  bombs  floating  into  aircraft  after  deployment,  due  to  the  influence 
of  the  aircraft  on  the  bomb's  aerodynamic  characteristics.  Those  types  of  experiences  and  other 
horror  stories  abounded  as  the  planning  for  the  aerodynamic  separation  between  the  Orbiter  and  the 
SCA  began. 

The  Space  Shuttle  already  had  two  parallel  separations  with  which  to  contend;  that  of  separating 
the  solid  rocket  boosters  from  the  external  tank  and  of  separating  the  external  tank  from  the 
orbiter.  Both  required  knowledge  of  the  aerodynamic  effects  when  the  vehicles  were  in  proximity, 
but  used  external  forces  to  affect  the  separation.  Knowledge  had  been  gained  in  testing  these 
launch  separation  configurations,  which  required  supersonic  test  facilities.  The  Orbiter/SCA 
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separation  required  testing  at  subsonic  speeds  and  so  required  that  different  support  mechanisms, 
stings,  and  facilities  be  utilized. 

The  wind  tunnel  tests  for  separation  were  conducted  with  the  Orbiter  and  SCA  mounted  on  separate 
balances  and  stings.  The  two  models  were  then  positioned  at  various  distances  apart  and  at  various 
relative  incidence  angles  to  obtain  the  data  necessary  to  simulate  the  separation  maneuver. 

The  amount  and  quality  of  the  data  obtained  from  these  tests,  and  the  analysis  of  the  separation 
trajectory  sensitivity  to  the  data,  resulted  in  the  elimination  of  two  complete  tests  scheduled  in 
the  wind  tunnel  test  program.  As  an  example,  the  analysis  showed  that  the  Orbiter  elevon  would  be 
deflected  only  a small  amount  for  either  pitch  or  roll  during  the  separation  maneuver.  This 
reduced  the  number  of  elevon  positions  required  to  be  tested.  The  deletion  of  those  tests  and 
streamlining  of  others  resulted  in  considerable  savings  to  the  program. 

A matrix  of  the  basic  configurations  tested  during  the  ALT  program  is  shown  in  figure  3.  The  mated 
Orbiter/SCA  basic  dimensions  and  configuration  details  are  shown  in  figure  4. 

The  utilization  of  mated  configuration,  separation  and  isolated  aerodynamic  data  in  computer 
simulations  provided  trajectory  information  about  the  relative  separation  distances  between  the 
vehicles.  Structural  clearance  was  the  initial  concern,  but  this  was  expanded  to  include  clearance 
between  the  Orbiter  and  the  vortex  wake  of  the  SCA. 

The  problems  associated  with  a trailing  vehicle  encountering  the  vortex  wake  of  a large  aircraft 
prompted  concerns  with  the  planned  separation  maneuver.  Separation  was  to  be  accomplished  by  the 
Orbiter/SCA  entering  a dive  maneuver  to  increase  airspeed,  followed  by  a reduction  of  power  and 
deployment  of  spoilers  to  reduce  lift  and  increase  the  drag  of  the  SCA.  Such  a configuration  was 
necessary  to  create  the  relative  motion  required  to  aerodynamically  drive  the  two  vehicles  apart. 
This  also  resulted  in  a near  maximum  vortex  wake  condition  since  the  SCA  was  now  closely  configured 
to  a landing  configuration. 

No  vortex  wake  test  was  scheduled;  however,  a Boeing  747  model  was  available  in  an  ongoing  Langley 
wind  tunnel  test.  The  sponsors  of  the  test  program  granted  JSC  one  evening  to  test  the  separation 
configuration  for  vortex  wake  information.  A "wing"  model  was  positioned  in  the  vortex  wake  area 
behind  the  Boeing  747,  and  rolling  moment  induced  on  the  wing  was  recorded.  This  information  was 
used  to  define  a turbulence  boundary  area.  Design  of  the  separation  maneuver  restricted  the 
Orbiter's  flight  path  to  remain  outside  the  area  of  turbulence.  Figure  5 depicts  the  area  of  the 
vortex  wake.  Data  from  the  vortex  wake  and  separation  tests  are  in  Ref.  1. 

ALT  FLIGHT  TEST  PROGRAM  OVERVIEW 


The  ultimate  aims  of  the  flight  test  program  were  to  certify  the  Orbiter/SCA  configuration  for 
ferry  flight  and  to  test  the  Orbiter  approach  and  landing  phase.  In  order  to  flight  test  the 
Orbiter,  a separation  maneuver  was  required  and  an  initial  part  of  the  flight  test  program  was 
designed  to  assure  that  the  separation  was  viable. 

The  first  test  of  the  mated  vehicles  consisted  of  taxi  testing  only.  This  was  followed  by  flight 
tests  of  the  Orbiter,  unmanned  and  unpowered,  atop  the  SCA.  The  Orbiter  with  tailcone  attached  was 
used  for  these  initial  flights  since  this  was  the  most  conservative  configuration  with  respect  to 
buffet  on  the  SCA.  This  was  also  the  selected  ferry  configuration. 

A load  measurement  system  was  developed  for  the  Orbiter/SCA  to  measure  and  record  the  attach  forces 
between  the  two  vehicles  during  the  mated  portion  of  each  flight.  Load  cells  instrumented  to 
measure  axial  and  shear  forces  were  located  on  each  of  the  three  Orbiter/SCA  attach  struts  shown  on 
Figure  4. 

Relative  vertical  and  side  forces  were  measured  at  the  forward  attach  strut.  Relative  vertical  and 
drag  forces  were  measured  at  the  left  aft  strut,  while  relative  vertical,  drag,  and  side  forces 
were  measured  at  the  right  aft  strut.  By  combining  these  measurements  mathematically,  the  relative 
normal  and  axial  accelerations  between  the  Orbiter  and  SCA  and  the  instantaneous  Orbiter  pitch 
acceleration  were  determined.  This  data  in  strip  chart  form  was  utilized  as  quicklook  information 
for  post  flight  analysis  and  subsequently  as  a basis  for  allowing  a realtime  decision  to  separate 
on  the  initial  tailcone-off  flight. 

A computer  program  was  developed  (Ref.  2)  which  could  take  the  aerodynamic  data  base  and  flight 
conditions,  such  as  airspeed,  and  compute  the  expected  loads  in  each  load  cell,  and  conversely, 
could  take  the  load  cell  data  and  extract  the  aerodynamic  coefficients.  Using  the  computer  program 
and  the  planned  flight  maneuvers,  a prediction  of  load  cell  readouts  could  be  made  prior  to  the 
flight.  Comparison  of  actual  and  predicted  load  cell  data  could  then  be  quickly  analyzed.  Further 
refinement  of  aerodynamic  data  was  also  possible  from  actual  flight  test  results. 
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Because  of  the  concern  for  the  SCA  vortex  wake,  several  flight  tests  were  made  to  confirm  the  wind 
tunnel  test  results.  The  initial  tests  consisted  of  a Lear  jet  and  a T-37  flown  behind  the  SCA. 
The  SCA  was  equipped  with  smoke  generators  and  the  aircraft  were  purposely  flown  into  the  smoke 
area  to  determine  the  affect  of  the  turbulence.  The  results  clearly  indicated  that  the  Orbiter 
should  remain  clear  of  this  area.  Subsequently,  an  F-104  was  flown  with  the  SCA  in  a simulated 
separation  maneuver.  In  this  test,  the  F-104  was  positioned  at  a point  off  the  SCA  wing, 
approximately  one  wing  span  away,  and  both  vehicles  flew  in  formation  through  a simulated 
separation  maneuver.  When  the  SCA  reached  its  conditions  for  separation,  the  F-104  pulled  away  and 
replicated  the  planned  Orbiter  maneuver  following  the  separation.  The  test  confirmed  that  adequate 
clearance  between  the  SCA  vortex  wake  and  the  Orbiter  flight  path  would  be  maintained. 


ORBITER/SCA  FLIGHT  TEST  RESULTS 


The  initial  flights  of  the  Orbiter/SCA  were  inert  tests  in  that  the  Orbiter  was  unpowered  and 
unmanned.  Five  flights  were  flown  in  this  series.  The  first  four  flights  were  used  to  obtain 
takeoff  and  climb  performance  data;  to  investigate  stability  and  control  envelopes,  flutter 
response,  and  buffet  and  loads  boundaries;  and  to  perform  airspeed  calibration  checks. 

The  fourth  flight  also  focused  on  evaluating  configuration  variables  associated  with  the  launch 
maneuver.  During  this  flight,  the  SCA  inflight  spoilers  were  deployed  for  the  first  time  and  the 
aircraft  performance  was  assessed  based  on  the  special  thrust  ratings  on  the  engines.  This  flight 
provided  engineers  their  first  look  at  a separation-related  parameter  in  the  form  of  the 
incremental  effect  of  the  inflight  spoilers  on  each  vehicle  in  close  proximity. 

The  fifth  flight  of  the  inert  series  obtained  data  during  two  simulated  launch  maneuvers  starting 
at  ceiling  altitude  and  terminating  after  approximately  20  seconds  of  steady-state  data  following 
the  "launch  ready"  call  by  the  SCA  pilot.  Both  vehicles  were  configured  as  they  would  be  for  an 
actual  separation  with  the  exception  of  the  Orbiter  elevon.  The  elevon  was  positioned  at  -1  degree 
for  emergency  jettison  for  these  early  flights. 

An  error  in  the  SCA  data  base  was  discovered  during  these  tests.  The  error  was  a result  of  the 
incorrect  use  of  wind  tunnel  incremental  data,  and  the  aerodynamic  data  base  was  updated  to  the 
actual  flight  data.  The  inert  tests  verified  that  (1)  the  Orbiter/SCA  configuration  could  achieve 
and  stabilize  on  the  separation  parameters  using  the  prescribed  procedures  without  exceeding 
Orbiter  or  SCA  constraints,  (2)  safe  separation  initial  conditions  could  be  achieved  with  the 
baseline  separation  configuration  and  airspeed,  and  (3)  the  mated  configuration  could  recover  from 
an  aborted  separation  maneuver  within  the  vehicle  constraints.  (Figure  6) 

Three  captive-active  flights  were  then  flown  with  the  Orbiter  manned.  The  objectives  of  these 
flights  were  to  verify  (I)  the  separation  configuration  and  procedures;  (2)  the  integrated 
structure,  aerodynamics,  and  flight  control  system;  and  (3)  the  Orbiter  integrated  system 
operations. 

The  first  captive-active  flight  was  restricted  in  airspeed  and  provided  no  separation  data.  The 
second  flight  included  a full  separation  simulation.  While  the  SCA  maintained  the  separation 
conditions,  the  Orbiter  crew  moved  the  rotational  hand  controller  (RHC)  full  forward  and  full  aft 
to  obtain  elevon  effectiveness  data.  Software  limits  restricted  the  elevon  to  move  up  1.5  degrees 
and  down  1.5  degrees  from  the  zero  degree  position  for  full  RHC  movement.  Each  position  was  held 
for  5 seconds  to  obtain  steady-state  data.  Data  from  the  load  cells  during  this  flight  test  were 
processed  through  the  computer  program  to  assess  the  elevon  effectiveness.  The  results  indicated  a 
shift  between  the  predicted  values  and  the  flight  test  data;  equivalent  to  an  approximately  -1 
degree  bias  in  the  Orbiter  elevon  position.  Otherwise,  the  effectiveness  of  the  elevon  was  in 
excellent  agreement  with  preflight  predictions. 

The  third  captive-active  flight  was  a dress  rehearsal  for  the  actual  separation.  The  elevon  was 
moved  from  the  climb  position  (-2  degrees)  to  the  separation  position  (0  degrees)  during  the 
maneuver.  The  elevon  bias  did  not  appear  during  this  test.  This  gave  rise  to  questions  regarding 
data  repeatabl il ity  and  elevon  position  calibration  accuracy.  Fortunately,  the  first  two 
separations  were  relatively  insensitive  to  small  elevon  dispersions;ie.  the  one  degree  uncertainty 
still  provided  an  adequate  separation  window.  During  the  pre-separation  maneuvers  on  these 
flights,  more  data  could  be  obtained  regarding  the  elevon  bias  for  use  in  establishing  separation 
conditions  for  more  sensitive  separations. 

To  design  the  separation  maneuver,  off-line  simulations  were  run  to  evaluate  clearances  and 
sensitivities.  Manned  simulations,  for  crew  training  were  made  for  the  Orbiter  and  the  SCA.  In 
these  manned  simulations,  the  trainer  vehicle,  either  Orbiter  or  SCA,  was  modeled  to  reflect  the 
proximity  aerodynamics.  The  SCA  was  modeled  as  the  mated  vehicle  until  separation  and  then  was 
influenced  by  predefined  proximity  aerodynamic  effects  as  it  was  flown  away  from  the  Orbiter.  The 
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Orbiter  flew  a predefined  profile  to  the  separation  point.  After  separation,  predefined  proximity 
aerodynamics  were  applied  while  it  was  under  the  influence  of  the  SCA. 

While  the  designers  felt  comfortable  with  their  work,  upper  management  was  still  concerned.  To 
better  represent  the  separation  to  management,  off-line  simulations  were  run  and  coupled  with 
computer  graphics  to  provide  a moving  picture  of  how  separation  would  be  accomplished.  After  the 
film  was  shown,  no  one  questioned  the  separation  maneuver. 

To  assess  the  performance  of  the  first  separation,  the  off-line  simulation  was  used  to  recreate  the 
flight  conditions,  using  load  cell,  downlist,  and  recorded  data  from  the  flight.  The  maneuver 
differed  from  planned  due  to  a larger  than  expected  Orbiter  pitch  up  rate  immediately  following 
separation.  This  was  probably  due  to  the  fact  that  an  onboard  computer  failed  at  the  instant  of 
separation  and  distracted  the  crew.  Comparison  of  the  off-line  simulation,  using  the  flight 
conditions  and  the  aerodynamic  data  base,  closely  paralleled  the  flight  results.  A discrepancy  in 
the  SCA  normal  load  factor  following  separation  was  attributable  to  the  difference  between  the  post 
separation  steering  maneuver  used  by  the  SCA  pilots  and  that  programmed  into  the  off-line 
simulation.  The  elevon  bias  was  not  evident  on  this  flight. 

The  second  separation  of  the  Orbiter  with  tailcone  attached  also  confirmed  the  preflight 
predictions.  On  this  flight,  the  Orbiter  pitch  up  acceleration  was  as  planned. 

The  third  flight  in  this  series  had  the  Orbiter  ballasted  to  a more  negative  center  of  gravity.  To 
compensate,  the  elevon  at  separation  was  set  at  2.5  degrees  and  the  airspeed  at  separation  was 
decreased  to  prevent  overloading  the  Orbiter  during  che  pitch  up  maneuver  following  separation. 
The  comparison  of  off-line  to  flight  results  was  again  in  close  agreement.  (Figure  7) 

The  Orbiter  without  the  tailcone  attached  presented  two  major  problems  with  the  separation  phase  of 
flight.  First,  the  increased  buffet  level  could  possibly  result  in  an  SCA  cockpit  environment  that 
would  make  it  impossible  for  the  SCA  to  attain  the  specified  target  conditions.  Second,  with  the 
removal  of  the  tailcone,  the  change  in  Orbiter  pitching  moment  required  +7  degrees  of  down  elevon, 
which  was  well  outside  the  elevon  range  tested  in  the  preceding  flights.  The  SCA  tail  loads  and 
climb  performance  degradation  created  by  the  increased  buffet  and  drag  levels,  respectively,  were 
also  unknowns.  A fourth  captive-active  flight  was  originally  planned  to  investigate  the  flight 
envelope  of  the  tailcone-off  configuration  but  was  deleted.  The  objectives  of  the  canceled 
captive-active  flight  were  combined  with  free  flight  4 and  were  evaluated  in  the  first  half  of  the 
flight.  The  optimum  incidence  for  tailcone  off  was  5 degrees  as  opposed  to  the  6 degrees  for 
tailcone  attached.  However,  to  reduce  the  number  of  variables,  it  was  decided  to  leave  the 
incidence  angle  at  6 degrees. 

The  first  portion  of  the  flight  was  dedicated  to  a realtime  assessment  of  the  buffet-induced  loads 
and  verification  of  the  separation  configuration  and  target  conditions.  A realtime  GO/NO-GO 
decision  for  separation  was  based  on  load  cell  data  telemetered  to  the  ground  and  displayed  on 
strip-charts  in  the  Dryden  Flight  Research  Center  control  room. 

The  buffet  levels  were  determined  to  be  acceptable  from  takeoff  to  maximum  airspeed  and  a 
separation  rehearsal  maneuver  was  initiated.  Had  the  data  not  matched  the  preflight  predictions,  a 
second  rehearsal  would  have  been  flown  to  obtain  elevon  effectiveness  over  the  untested  range.  The 
data  in  the  first  rehearsal , with  the  elevon  deflected  to  +7  degrees,  confirmed  the  preflight 
predictions  and  all  parameters  were  within  the  acceptable  separation  window.  A realtime  decision 
was  made  to  continue  with  the  actual  separation  maneuver.  Again,  post  flight  analysis  in  off-line 
simulations  agreed  well  with  actual  flight  data. 

The  fifth  flight  of  the  free  flight  series  was  a duplicate  of  the  first  from  the  separation 
viewpoint.  Again,  the  trajectory  reconstruction  showed  excellent  agreement  between  flight  data, 
including  photographic  time  histories,  and  off-line  simulation  data.  (Figure  7) 

DEVELOPMENT  OF  ORBITER  TAILCONE-ON  AERODYNAMIC  DATA  BASE 


The  decision  to  fly  the  initial  ALT  flights  with  the  tailcone  on  the  Orbiter  was  made  approximately 
one  year  prior  to  the  scheduled  flight  dates. The  short  lead  time  to  acquire  a preflight  tailcone-on 
aerodynamic  data  base  prompted  a flurry  of  wind  tunnel  testing  over  the  ALT  flight  regime 
of  Mach  0.8  down  to  touchdown.  Due  to  the  shape  and  location  of  the  tailcone,  much  of  the  testing 
involved  evaluation  of  various  model  support  systems  such  that  a primary  support  system  could  be 
selected.  This  testing  also  involved  evaluation  of  alternate  support  systems  such  that  tares  on 
the  primary  support  system  could  be  determined.  A summary  of  the  support  systems  evaluated  is 
presented  in  figure  8. 

Following  the  decision  to  utilize  a sting  as  the  primary  support  system,  sting  tares  were 
determined  in  a subsonic  wind  tunnel  test  while  supporting  the  model  with  wing  tip  mounted  dual 
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struts,  as  shown  in  configuration  6 of  figure  8.  Those  tares  were  applied  to  the  test  results  for 
the  Mach  0.4  to  0.8  regime,  assuming  Mach  effects  to  be  negligible.  Further  testing 
utilizing  support  configuration  5 of  figure  8 provided  verification  of  the  validity  of  that 
assumption. 

Wind  tunnel  testing  at  Mach  0.20  to  0.25  was  not  only  accomplished  through  use  of  the  previously 
mentioned  wing  tip  mounted  dual  struts  and  sting  support  systems,  but  involved  utilization  of  a 
triple-strut  mounted  0.36-scale  model,  figure  9,  in  the  Ames  Research  Center  40x80-ft  facility. 
Previously  determined  triple-strut  tares  from  Orbiter  tailcone-off  testing  were  utilized  during  the 
0.36-scale  tailcone-on  test. 


ORBITER  AERODYNAMIC  PERFORMANCE  COMPARISONS 

Orbiter  flight  test  data  from  the  ALT  program  were  obtained  from  both  quasi -steady  state  and 
dynamic  flight  test  conditions.  Flight  data  utilized  herein  was  determined  from  references  3,  4, 
and  5.  The  dynamic  test  maneuver  occurred  with  tailcone  off  and  consisted  of  a pushover-pul  1 up 
maneuver  providing  an  angle  of  attack  range  from  2 to  16  degrees  in  a relatively  short  time.  Mach 
number  was  virtually  unchanged  during  the  maneuver. 

The  predicted  data  used  for  comparison  with  the  flight  test  data  was  determined  from  the 
Aerodynamic  Design  Data  Books  (ADDB),  references  6 and  7,  using  given  flight  attitudes,  Mach 
numbers,  and  control  surface  deflections.  Aerodynamic  "tolerances"  and  "variations"  shown  on  the 
performance  comparison  figures  were  also  obtained  from  the  referenced  ADDB's.  "Variations"  were 
derived  utilizing  past  flight  test  experience  from  many  representati ve  aircraft  and  represents  an 
uncertainly  between  wind  tunnel -derived  and  flight-derived  aerodynamic  coefficients.  "Tolerances" 
represent  only  the  uncertainty  related  to  the  wind  tunnel  predictions  due  to  data  scatter  and 
scatter  resulting  from  testing  with  various  models  and  in  various  wind  tunnel  facilities. 

The  aerodynamic  analyst  is  faced  with  a dilemma  in  the  comparison  of  preflight  predictions  and 
flight  test  data.  In  wind  tunnel  testing,  which  is  the  basis  of  the  preflight  predictions,  the 
independent  parameters  are  known  precisely  while  the  aerodynamics  are  questionable.  In  flight 
testing,  the  aerodynamics  are  known  exactly,  by  definition,  but  the  accuracy  of  the  independent 
parameters  may  be  in  question.  To  minimize  the  impact  of  this  dilemma,  the  aerodynamic  comparisons 
were  selected  such  that  errors  in  the  flight-independent  parameters  are  minimized.  Thus, 
lift-to-drag  ratio  (L/D)  was  selected  for  comparisons  of  predicted  and  flight  aerodynamic 
performance,  since  it  is  independent  of  flight  dynamic  pressure  (q). 

Tailcone-on  L/D,  illustrated  in  figure  10,  indicates  a slight  reduction  in  flight  data  relative  to 
the  predictions.  The  lift  and  drag  coefficients  presented  in  figure  11  indicate  that  at  the  same 
lift  coefficient,  drag  coefficient  from  flight  is  slightly  higher  than  that  predicted,  thus 
reducing  L/D  from  the  predicted  levels.  It  should  also  be  noted  that  both  lift  and  drag 
coefficients  are  well  within  the  predicted  tolerance  and  variation  limits  indicated. 

Figure  12  presents  tailcone-off  L/D  at  an  average  Mach  number  of  0.4.  The  maximum  flight  L/D  is 
approximately  the  same  as  predicted;  however  at  the  lower  values  of  lift  coefficient  the  flight  L/D 
is  slightly  higher  than  predicted.  As  seen  in  figure  13,  both  lift  and  drag  coefficients  as  a 
function  of  angle  of  attack  are  slightly  less  than  predicted,  although  the  flight  lift  curve  slope 
is  very  close  to  predicted.  Comparison  of  drag  coefficient  at  the  same  lift  coefficient  does 
indicate  that  flight  drag  coefficient  is  slightly  less  than  predicted,  thus  the  slight  increase  in 
flight  L/D.  Again,  both  lift  and  drag  coefficients  are  well  within  the  predicted  tolerance  and 
variation  limits  indicated. 

An  area  of  concern  which  has  been  verified  by  the  flight  test  data  is  ground  effects,  which  were 
primarily  confined  to  main  gearwheel  heights  (h  ) of  less  than  twenty  feet,  as  illustrated  in 
figure  14.  For  both  tailcone-on  and  tail cone-Hff  configurations,  the  flight  incremental  lift  due 
to  ground  effects  compared  well  with  predicted  data.  The  ground  effect  on  drag  coefficient  is 
negligible  and,  therefore,  is  not  presented. 

Estimates  of  flight  landing  gear  axial  force  and  drag  indicate  that  the  incremental  effect  of 
landing  gear  was  over  predicted,  due  probably  to  not  correcting  the  low-speed,  low-Reynolds  number 
wind  tunnel  test  results  to  flight  Reynolds  number.  A post  flight  wind  tunnel  test  was  conducted 
utilizing  a large  (0.05-scale)  high  fidelity  model  at  a high  Reynolds  number.  The  results  of  that 
test  are  shown  in  figure  15  and  agree  quite  well  with  the  landing  gear  axial  force  and  drag 
coefficients  as  derived  from  the  flight  tests. 
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CONCLUSIONS 


The  analytical  prediction  techniques  and  mathematical  modeling  incorporated  in  the  design  of  the 
separation  procedures  for  the  Orbiter/SCA  were  based  on  scale-model  wind  tunnel  test  data.  These 
techniques  proved  to  be  extremely  accurate  and  useful  throughout  the  Approach  and  Landing  Test 
Program. 

The  load  measurement  system  installed  aboard  the  SCA  provided  a means  for  extracting  the  proximity 
aerodynamics  and  was  a reliable  source  for  making  realtime  assessments  of  separation  and  loads 
parameters.  The  load  measurement  system  also  allowed  some  wind  tunnel  tests  to  be  deleted  form  the 
program,  with  actual  flight  data  completing  the  aerodynamic  data  base.  The  Orbiter  separated  from 
the  SCA,  successfully  and  as  predicted,  five  times  during  the  ALT  program 

During  the  Approach  and  Landing  Test  Program  the  Space  Shuttle  Orbiter  was  flown  as  both 
tailcone-on  and  tailcone-off  configurations.  Due  to  the  shape  and  location  of  the  tailcone  on  the 
Space  Shuttle  Orbiter,  much  of  the  initial  wind  tunnel  testing  required  to  support  the  Approach  and 
Landing  Test  Program  requirement  to  fly  some  flights  with  the  tailcone  on  involved  evaluation  of 
various  model  support  systems.  From  these  tests  a primary  support  system  consisting  of  an  aft 
mounted  sting  was  selected.  Support  systems  consisting  of  both  wingtip  mounted  struts  and  lower 
forward  fuselage  strut  were  utilized  to  evaluate  and  verify  sting  tares. 

Comparisons  of  predicted  and  flight  test  performance  data  indicate  that  lift-to-drag  ratio,  lift 
coefficient,  and  drag  coefficient  were  well  within  predicted  tolerance  and  variation  limits  for 
both  tailcone-on  and  tailcone-off.  The  flight  incremental  lift  due  to  ground  effects  also  compared 
well  with  predicted  data. 

The  flight-derived  axial  force  and  drag  indicate  that  the  incremental  effect  of  the  landing  gear 
was  over  predicted,  due  probably  to  not  correcting  the  low-speed,  low-Reynolds  number  wind  tunnel 
results  to  flight  conditions.  A post  flight  high-Reynolds  number  wind  tunnel  test  confirmed  the 
flight  test  results. 
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GEOMETRY 
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TAPER  RATIO 
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SWEEP  (LE) 

81/45  DEG 

45  DEG 

DIHEDRAL 

3.5 

INCIDENCE 

0.5  DEG 

— _ 

MAC 

474.81  (12.0602) 

199.81  (5.0752) 

NOTE:  UNLESS  OTHERWISE  NOTED,  ALL  DIMENSIONS 
ARE  IN  INCHES  (METERS) 


Figure  1. 


Space  Shuttle  Orbiter  Tailcone-off  Configuration. 


Figure  2.  Space  Shuttle  Orbiter  Tailcone-on  Configuration. 


Figure  3. 


Ferry  and  Approach  and  Landing  Test  Program  Wind  Tunnel 
Configuration  Matrix. 


MEASUREMENT 
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ORBITER 

WING 
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WING 
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AREA,  m2 
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37.5  (1/4  c) 

a45 

a45 

DIHEDRAL,  DEG 

7.0 

— 

7.0 

b3.5 

— 

INCIDENCE,  DEG 

2.0 

— 

1 +5  TO -10 

0.5 

— 

MAC,  cm 

8.3 

8.5 

6.9 

12.1 

5.1 

aLEADING  EDGE. 

^TRAILING  EDGE. 

CMEAN  AERODYNAMIC  CHORD. 


DIMENSIONS  IN  METERS 


Figure  4.  Mated  Space  Shuttle  Orbi ter/Carrier  Aircraft  Configuration. 
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Figure  5. 


SCA  Vortex  Wake  Definition. 
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Figure  6 


Inert  Flight  5:  Flight  Test 


FLIGHT  5 SCA  AERODYNAMICS  WITH 
ORBITER  ATTACHED 
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Figure  7. 


Comparison  of  Separation  Clearances  Between  Flight  Test  and 
Predicted  Data 
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Figure  8. 


Model  Support  Systems  Evaluated  during  Tailcone-on  Wind 
Tunnel  Testing. 


Figure  9.  Triple-Strut  Support  System  Utilized  with  the  0.36-scale 
Model  Orbiter. 
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Figure  10. 


Tailcone-on  Performance  Comparisons  of  Flight  Test  and 
Predicted  Data. 
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Figure  11.  Tailcone-on  Lift  and  Drag  Coefficient  Comparisons 
of  Flight  Test  and  Predicted  Data. 


.7  r- 


Figure  12.  Tailcone-off  Performance  Comparisons  of  Flight  Test  and 
Predicted  Data. 
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Figure  13. 


Tailcone-off  Lift  and  Drag  Coefficient  Comparisons 
of  Flight  Test  and  Predicted  Data. 
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Figure  14.  Incremental  Lift  Coeffiecient  due  to  Ground  Effect. 


ORBITER  102  WIND  TUNNEL  TEST  DATA 
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Figure  15.  Incremental  Axial  Force  and  Drag  Coefficients 
due  to  Landing  Gear  Deployed. 
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ABSTRACT 


Air  data  parameters  are  required  during  Orbiter  atmospheric  entry  for  use  by  the  auto- 
guidance, navigation,  and  flight  control  systems,  and  for  crew  displays.  Conventional  aircraft 
calibrations  of  the  Orbiter  air  data  system  were  not  practicable  for  the  Space  Shuttle,  therefore 
extensive  wind  tunnel  testing  was  required  to  give  confidence  in  the  preflight  calibrations.  Many 
challenges  became  apparent  as  the  program  developed;  in  the  overall  system  design,  in  the  wind 
tunnel  testing  program,  in  the  implementation  of  the  air  data  system  calibration,  and  in  the  use 
of  the  flight  data  to  modify  the  wind  tunnel  results.  These  challenges  are  discussed  along  with 
the  methods  used  to  solve  the  problems. 


NOMENCLATURE 


SYMBOLS 


c 

pfl 

Static  pressure  coefficient 

s 

M 

Mach  number 

pc 

Center  port  (pressure) 

PL 

Lower  port  (pressure) 

PM 

Measured  static  pressure 

PS 

Static  pressure  (port) 

PT 

Total  pressure  (port) 

PU 

Upper  port  (pressure) 

i 

Dynamic  pressure 

T 

T 

Total  temperature 

X 

Orbiter  vehicle  X-station 

Y 

Orbiter  vehicle  Y-station 

a 

Angle  of  attack 

P 

Angle  of  sideslip 

SUBSCRIPTS 

C Calibration-corrected  value 

CAL  Calibration  parameter  value 

m Measurement  by  air  data  probe 

WT  Wind  tunnel 

00  Free-stream  value 


ACRONYMS 

ADS  Air  data  system 

ADTA  Air  data  transducer  assembly 

ALT  Approach  and  landing  test 

A/L  Approach  and  landing 

ARC  Ames  Research  Center 

FRL  Fuselage  reference  line 

FS  Fuselage  X-station 

FTB  Flight  test  boom  (flight  test  probe  and  mast) 

GN&C  Guidance,  navigation  and  control 

GPC  General  purpose  computer 

IMU  Inertial  measurement  unit 

LaRC  Langley  Research  Center 

LeRC  Lewis  Research  Center 

MS  Model  X-station 
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NAAL  North  American  Aerodynamics  Laboratory 

NASA  National  Aeronautics  and  Space  Administration 

OA  Orbiter  aerodynamics  test  series 

OFT  Orbital  flight  test 

OML  Outer  mold  line 

STS-1  First  space  transportation  system  flight  (OFT) 

TAEM  Terminal  area  energy  management 

TPS  Thermal  protection  system 

WL  Fuselage  water  line 

WP  Fuselage  water  plane 


INTRODUCTION 


The  NASA  Space  Shuttle  is  designed  as  a reusable  transportation  system  to  near  Earth  orbit. 
The  prime  element  of  the  total  Space  Shuttle  configuration  is  the  payload  - carrying  Orbiter. 
Subsequent  to  launch  and  orbital  operations  the  Orbiter  must  be  able  to  negotiate  the  critical 
entry  portion  of  the  flight  and  land  safely  on  a conventional  runway.  During  the  entry  phase,  the 
Orbiter  configuration  must  maintain  stability  and  control  as  well  as  a required  trim  attitude,  for 
large  center  of  gravity  position  changes  and  a large  angle  of  attack  span  (the  latter  from  heating 
and  ranging  considerations).  Mach  number  varies  from  28  at  initial  entry  to  approximately  0.25  at 
landing,  and  the  angle  of  attack  varies  from  40  degrees  to  0 degrees.  During  entry  to  touchdown, 
the  automatic  flight  control  system  passes  through  three  distinct  phases:  entry,  terminal  area 

energy  management  (TAEM)  and  approach  and  landing  (A/L).  Each  of  these  phases  has  established 
requirements  for  processed  air  data,  such  as  angle  of  attack,  altitude,  Mach  number,  etc.,  from 
the  Orbiter  air  data  system  (ADS)  for  the  conditions  shown  in  table  I. 

In  many  ways,  the  Orbiter  ADS  is  a typical  ADS.  It  uses  two  fuselage-mounted  probes  to 
measure  local  flow  conditions.  Freestream  conditions,  such  as  Mach  number,  angle  of  attack,  and 
altitude  are  computed  using  previously  derived  calibration  algorithms.  The  freestream  conditions 
are  used  by  the  guidance,  navigation  and  control  (GN&C)  system  and  are  also  displayed  to  the  crew. 
In  addition,  air  data  are  used  extensively  during  the  postflight  aerodynamic  analyses. 

In  terms  of  obtaining  accurate  preflight  air  data  calibrations  for  the  Orbiter  there  existed 
a somewhat  unique  situation.  The  typical  aircraft  flight  calibration  was  not  practicable  (i.e. 
tower  flyby,  pacer  aircraft,  etc.  type  testing  was  not  compatible  with  any  sustained  Orbiter  test 
flight  conditions).  In  addition,  the  blunt  nose  of  the  Orbiter  causes  large  "position  errors" 
that  must  be  accounted  for  in  the  calibration.  Because  of  all  the  aforementioned  conditions,  an 
extensive  wind  tunnel  calibration  program  was  required.  The  approach  and  landing  test  (ALT)  phase 
of  the  flight  test  program  had  a conventional  flight  test  boom  (FTB)  installed  in  the  nose  of  the 
Orbiter  for  the  purpose  of  evaluating  the  subsonic  wind  tunnel  calibration  of  the  ADS.  The  wind 
tunnel  data  were  merged  with  data  obtained  during  the  ALT  program  to  produce  an  on-board 
calibration  for  orbital  flight  test  (OFT)  and  a more  accurate  calibration  for  the  postflight 
aerodynamic  analyses.  Results  from  the  OFT  program  indicated  that  the  on-board  calibration  easily 
met  the  specified  requirements.  These  results  were  also  used  in  an  extensive  effort  to  refine  the 
postflight  calibration  in  order  to  provide  the  best  possible  data  for  the  postflight  aerodynamic 
analyses . 


SYSTEM  DESCRIPTION 


A sketch  of  the  Orbiter  ADS  probes  illustrating  their  location  on  the  Orbiter  nose  is  shown 
in  figure  1.  There  are  two  probes,  one  on  either  side  of  the  vehicle.  They  are  secured  to 
rotating  doors  that  allow  them  to  be  stowed  (and  thus  protected)  during  ascent,  orbit,  and  initial 
re-entry.  The  probes  are  deployed  during  re-entry  when  the  Orbiter  has  slowed  to  approximately 
Mach  3.5.  Each  probe  includes  a semispherical  head  with  three  pressure  measurements.  The  center 
port  (Pq)  gives  an  indication  of  total  pressure  (P^  ),  and  senses  local  total  pressure  when  the 

m 

probe  is  aligned  with  the  local  flowfield.  The  upper  and  lower  ports  (P^  and  P^)  are  sensitive  to 

local  flow  angle.  In  addition,  several  static  pressure  ports  (Pg  ) are  located  aft  on  the  probe 

m 

shaft,  and  a total  temperature  (T^)  sensor  is  located  at  the  rear.  The  probes  are  connected  to 

four  air  data  transducer  assemblies  (ADTA's),  redundant  pairs  per  side,  through  pneumatic  lines. 
The  ADTA's  house  pressure  transducers  that  convert  the  probe-measured  pressures  to  electrical 
signals.  Using  the  ADS  calibrations,  the  general  purpose  computer  (GPC)  processes  the  ADTA 
signals  to  provide  the  basic  air  data  parameters:  static  pressure,  total  pressure,  and  angle  of 

attack.  From  these  basic  parameters,  Mach  number,  dynamic  pressure,  pressure  altitude,  equivalent 
airspeed,  and  true  airspeed  are  computed. 
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The  ADS  calibration  relates  a set  of  conditions  that  cannot  be  measured  directly  during 
flight  (i.e.,  Mach  number,  angle  of  attack,  etc.)  to  a set  of  parameters  that  can  be  measured 
(i.e.,  probe  total,  static,  upper  and  lower  pressures,  and  total  temperature).  In  the  wind 
tunnel,  specific  freestream  conditions  (i.e.,  static  and  total  pressure,  angle  of  attack,  and  Mach 
number)  are  known  to  a relatively  high  degree  of  accuracy.  During  a wind  tunnel  test  these 
conditions  are  held  constant,  while  the  probe  pressures  are  carefully  measured  and  recorded.  A 
schematic  depicting  the  relationship  between  wind  tunnel  and  flight  measurements/calibration  is 
shown  in  figure  2.  The  flight  probe  measurements  are  channeled  through  the  calibration  software 
to  calculate  the  air  data  parameters  as  shown  in  figure  3. 

Some  of  the  more  obvious  "system"  challenges  for  the  Orbiter  ADS  were  deployment/storage 
capability  and  system  redundancy.  A definition  of  when  ADS  deployment  would  occur  depended  on  a 
trade  between  the  high  heat  environment  that  occurs  early  in  re-entry  and  where  ADS  information  is 
needed  to  increase  the  GN&C  system  performance  levels.  From  heating  information  and  entry 
simulations  a value  near  Mach  3.5  was  agreed  on.  In  actual  practice  the  ADS  parameters  are 
computed  in  the  GPC,  compared  with  other  available  sources,  as  well  as  with  the  redundant  air  data 
sources,  then  if  deemed  good  data,  used  at  Mach  2.5  and  below. 

Redundancy  was  built  into  the  system  by  having  two  probes  (right  and  left)  and  two  separate 
ADTA's  for  each  pressure  measurement.  Because  of  this  redundancy  four  sets  of  air  data  parameters 
were  produced  and  a rating  system  was  used  for  selection  of  the  "best"  data.  A more  detailed 
assessment  of  the  ADS  estimated  performance  and  the  system  definition  can  be  found  in  references  1 
and  2. 


WIND  TUNNEL  TEST  PROGRAM 

The  ADS  wind  tunnel  calibration  development  program  initially  consisted  of  one  low  subsonic 
calibration  test  of  a complete  0.36  scale  Orbiter  with  0.36  scale  side  probes;  one  transonic  test, 
one  low  supersonic  test,  and  one  high  supersonic  test  of  a 0.10  scale  forebody  model  with  0.20 
scale  side  probes.  Because  of  physical  size  limitations,  for  the  transonic  and  supersonic  tests 
the  smallest  side  probes  that  could  be  tested  with  at  least  pitot-static  instrumentation  or  upper 
and  lower  pressure  instrumentation  in  each  probe,  was  0.20  scale.  The  largest  model  size  that 
could  be  tested  without  introducing  significant  blockage  was  0.10  scale,  resulting  in  a model- 
scale,  probe-scale  difference.  Due  to  test  data  problems  related  to  the  scale  difference  the  wind 
tunnel  test  program  was  expanded  in  the  Orbiter  aerodynamics  (OA)  series  to  that  shown  in  table 
II. 


Prior  to  wind  tunnel  model  design  and  testing  philosophy  many  compromises  had  to  be  decided 
upon.  The  full-scale  Orbiter  vehicle  is  over  107  feet  long  and  the  side  probes  are  approximately 
1 foot  long.  Testing  facilities  have  model  size  constraints  that  were  pushed  to  the  limit.  There 
were  no  model  scaling  problems  with  the  0.36  scale  Orbiter.  There  were  however,  problems 
retaining  the  configuration  fidelity  on  the  0.10  scale  forebody  model.  In  this  case  the  model  had 
to  be  shortened  and  was  boat-tailed  in  the  region  of  fuselage  station  670  (full-scale)  as  shown  in 
figure  4.  In  addition,  as  previously  mentioned,  the  side  probes  were  0.20  scale  in  order  to  get 
two  of  the  four  pressure  lines  in  one  side  probe  (for  PU  and  PL),  and  two  in  the  other  probe  (for 
PS  and  PT).  As  much  geometric  similarity  as  possible  was  retained  in  the  region  of  the  side 
probes.  For  determining  probe  scale  effects,  the  static  pressure  port  standoff  distance  (Ypg)  and 

X-model  station  location  (Xpg)  were  correctly  simulated.  For  total  pressure  and  angle  of  attack 

measurements,  the  0.20  scale  probe  was  moved  aft  such  that  the  probe  tip  X-station  corresponded  to 
a 0.10  scale  probe  tip  X-station.  Further  model/configuration  duplication  problems  resulted 
because  only  a portion  of  the  wing  root  could  be  retained.  The  effects  of  all  of  these 
model/full-scale  vehicle  differences  on  the  probe  measurements  were  investigated.  In  addition, 
differences  in  the  vehicle  outer  mold  line  (OML)  between  the  initial  lines  and  the  final 
configuration  lines  were  assessed.  The  solution  to  these  model  scale  and  model  fidelity  problems 
was  to  use  theoretical  calculations  where  possible  and  run  supplementary  tests  otherwise. 

Potential  flow  calculations  were  used  to  determine  the  effects  of  afterbody  closure  (boat-tail), 
model/probe  scale  mismatch,  and  OML  duplication.  Effects  of  the  wing  root/leading  edge  exclusion 
was  measured  in  test  OA-22.  The  results,  in  the  form  of  pressure  increments,  were  added  to  the 
basic  data  and  an  estimated  uncertainty  added  in  the  accuracy  analysis. 

Data  problems  that  resulted  later  during  the  actual  testing  were:  facility  reference  static 

pressure  differences,  effects  of  model/probe  scale  mismatch  (for  the  0.10  scale  forebody  model), 
OML  differences,  and  wind  tunnel  blockage  effects.  Facility  reference  conditions  are  dependent  on 
when  and  how  each  facility  performs  their  calibrations.  The  reference  conditions  were 
investigated  by  testing  several  standards  and  calibration  devices  that  were  available  and 
comparing  these  with  a slender  cone-cylinder  probe  furnished  by  the  manufacturer  of  the  side 
probes.  The  results  indicated  differences  from  the  reference  probe  from  +1.0  percent  to  -1.5 
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percent  of  q.  During  the  later  ascent  air  data  system  wind  tunnel  calibration  program  similar 
3 

procedures  were  used.  These  corrections  were  applied  to  all  data  used  in  subsequent  analyses. 

The  effect  of  model/probe  scale  mismatch  (subsonically ) is  detailed  in  reference  2.  Basically  a 
larger  effect  was  found  from  that  estimated  earlier  by  the  theory,  particularly  at  angles  of 
attack  where  the  theory  assumes  zero  angle  of  attack.  The  effect  of  OML  changes  is  also 
delineated  in  reference  2.  Here,  because  of  quite  drastic  configuration  modifications  in  the  nose 
area  a new  0.10  scale  forebody  was  constructed.  Blockage  effects  were  also  determined  by  testing. 
Test  OA237  was  conducted  using  the  smaller  (0.10)  scale  model  and  the  results  were  compared  to  the 
larger  (0.36)  scale  model  that  was  tested  previously  is  this  same  facility.  All  of  these 
aforementioned  testing  problems  are  discussed  in  more  detail  in  reference  4. 


CALIBRATION  FORMULATION/ IMPLEMENTATION 

The  development  of  the  ADS  calibration  involved  deriving  a set  of  calibration  parameters  that 
relate  the  freestream  conditions  to  the  probe-measured  conditions,  using  the  wind  tunnel  derived 
data  base.  From  the  freestream  conditions,  the  various  air  data  parameters  (Mach  number, 
altitude,  etc.)  can  be  computed  using  basic  aerodynamic  equations.  Analysis  of  the  static 
pressure  coefficient  with  Mach  number  indicated  a "Mach  Jump"  region  of  extremely  non-linear  data. 
As  the  free  stream  Mach  number  increases  to  1.0  and  greater,  a bow  shock  is  formed  that  stands  off 
the  Orbiter  nose.  The  bow  shock  delays  the  local  Mach  number  at  the  side  probe  from  reaching 
sonic  speeds  until  the  free-stream  Mach  number  is  in  the  range  of  1.2  to  1.4.  When  the  local  flow 
reaches  sonic  speeds  a very  large  rise  in  measured  static  pressure  occurs  and  is  referred  to  as 
the  static  pressure  ''Mach  Jump".  Figure  5 shows  the  variability  of  static  pressure  coefficient 
with  Mach  number.  To  avoid  the  extreme  non-linearities  in  the  onboard  software  implementation, 
static  pressure  is  derived  from  a GPC  stored  standard  atmosphere  model  for  Mach  numbers  from  0.9 
to  1.6. 

Analyses  of  the  wind  tunnel  data  calibration  parameters  resulted  in  a set  of  polynomial 
equations  with  over  600  coefficients.  For  the  on-board  calibration,  software  storage  limitations 
dictated  200  or  less  coefficients.  Studies  to  reduce  the  number  of  coefficients  indicated  that  by 
fitting  the  polynomials  to  concentrate  on  nominal  trajectory  conditions  the  number  of  coefficients 
could  be  reduced  to  196. 

Another  potential  error  source  was  the  on-board  initialization  of  the  calibration.  The 
system  begins  with  the  previous  Mach  number  (initially  an  assumed  Mach  number)  to  enter  the 
calibration  equations,  but  does  not  iterate  with  a corrected  Mach  number.  Prior  to  STS-1,  it  was 
analytically  shown  that  the  rate  of  change  of  Mach  number,  and/or  the  calibration  coefficients, 
was  low  enough  to  preclude  a significant  error.  This  analysis  has  been  verified  by  flight 
results . 


FLIGHT  DATA  ANALYSES 


Post  flight  data  from  the  ALT  series  were  used  to  adjust  the  ADS  calibrations  in  the  subsonic 
flight  regime.  Data  from  the  OFT  series  was  used  to  adjust  the  ADS  calibrations  at  the  higher 
Mach  numbers,  where  much  smaller  modifications  were  required. 


APPROACH  AND  LANDING  FLIGHT  DATA 

The  ALT  phase  of  the  flight  test  program  had  a conventional  flight  test  boom  (FTB)  installed 
in  the  nose  of  the  Orbiter  for  the  purpose  of  evaluating  the  subsonic  wind  tunnel  calibration  of 
the  ADS  using  data  from  the  FTB  as  a reference.  In  addition  to  FTB  data,  ground  data  in  the  form 
of  radar  and  phototheodolite  tracking,  combined  with  weather  balloon  data,  were  used  to  verify  the 
FTB.  In  order  that  the  FTB  data  be  used  to  correct  the  wind  tunnel  data,  all  potential  sources  of 
error  had  to  be  eliminated  or  accounted  for.  Adjustments  and  compensations  were  made  to  the  FTB 
attitude  data  for  the  following  effects:  aerodynamic  flowfield  upwash  and  offset,  FTB  incidence 

and  mounting  misalignment,  change  in  the  aerodynamic  flowfield  due  to  vehicle  pitch  rate,  and  FTB 
structural  deflections  due  to  normal  acceleration,  pitch  acceleration,  and  airloads.  Pressure 
coefficients  from  the  FTB  were  seen  to  be  very  accurate,  with  no  calibration  required  for  total 
pressure  and  only  small  adjustments  for  static  pressure.  The  resulting  flight  data  from  the  ALT 
series  was  used  with  the  transonic  and  supersonic  wind  tunnel  data  to  formulate  the  calibration 

for  the  OFT  series. ^ 
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ORBITAL  FLIGHT  TEST  DATA 


The  ADS  calibration  for  OFT  proved  to  be  adequate  for  on-board  use  (see  table  I).  For  post- 
flight aerodynamic  analysis,  however,  further  refinements  were  developed  from  the  flight  programs 
to  produce  the  best  possible  air  data  parameters  for  postflight  analysis  work.  From  Mach  3.5  to 
Mach  0.6,  the  meteorological  static  pressure  was  substituted  for  that  derived  by  the  ADS.  From 
Mach  0.6  to  landing  gear  deployment,  corrections  derived  from  a regression  analysis  technique  were 
applied  to  angle  of  attack,  static  pressure,  and  total  pressure.  The  resulting  ADS  calibration 
has  generated  air  data  that  has  been  used  in  conjunction  with  flight-derived  aerodynamic  data  to 

evaluate  the  performance  of  the  Orbiter  during  re-entry. 


SUMMARY 


The  Shuttle  ADS  calibration  was  difficult  to  obtain  because  of  the  Orbiter  unique  flight 
regime,  configuration,  and  operational  characteristics.  System  challenges  involved  when  to  deploy 
the  ADS  probes  to  avoid  reentry  heating  and  how  to  handle  the  ADS  redundancy  requirement.  During 
the  wind  tunnel  calibration  data  discrepancies  surfaced,  with  the  major  problems  identified  as: 
facility  reference  pressure,  model/probe  scale  differences,  OML  changes  and  blockage  effects. 
Calibration  implementation  challenges  were  "Mach  Jump",  on-board  software  limitations  and  air  data 

calculation  initialization.  Each  of  these  problems  was  surmounted  by  careful  analysis  of  the 
existing  data  and  by  thorough  design  of  supplementary  testing  to  resolve  the  data  discrepancies. 
Testing  hardware  and  techniques  were  modified  for  on-going  testing  as  required.  The  resulting 
preflight  calibrations  were  modified  using  the  ALT  data  (subsonic  flight)  to  formulate  the  OFT 
calibration.  Post-flight  comparisons  of  OFT  data  showed  the  calibration  to  be  adequate  for 
operational  flight.  Further  refinements  were  made,  however,  to  assist  in  the  evaluation  of  the 
aerodynamic  characteristics  of  the  Orbiter. 
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Orbiter  Air  Data  System  Parameter  Requirements 


Table  I. 


SYSTEM  REQUIREMENT 

AIR  DATA  PARAMETER 

SYMBOL 

UNITS 

FLIGHT 

PHASE 

UTILIZATION 

RANGE 

ACCURACY 
{%  OF  READING 
UNLESS  NOTED) 
(3o) 

CREW 

DISPLAY 

GEODETIC  ALTITUDE 
(PRESSURE  ALTITUDE 
CORRECTED  FOR  NON- 
STANDARD ATMOSPHERE) 

hpc 

FT 

ENTRY  & TAEM 

10K  TO  100K 

±10% 

YES 

PRESSURE  ALTITUDE 
RATE  (SINGLE  PROBE 
OPERATION  ONLY) 

h 

FPS 

TAEM 

A/L 

0 TO  -600 
0 TO  -250 

±10  FPS  OR  ±5% 
W/E  IS  GREATER 
±2  FPS  OR  ±5% 
W/E  IS  GREATER 

YES 

DYNAMIC  PRESSURE 

q 

PSF 

TAEM  & A/L 

90  TO  375 

±10% 

NO 

MACH  NUMBER 

M 

— 

TAEM 

A/L 

0.6  TO  2.5 
0.25  TO  0.6 

±10% 

±10% 

YES 

TRUE  AIRSPEED 

VT 

FPS 

TAEM 

A/L 

600  TO  2500 
250  TO  600 

±10% 

±10% 

NO 

EQUIVALENT  AIRSPEED 

Ve 

KTS 

FPS 

TAEM  & A/L 
A/L 

160  TO  335 
112  TO  270 

+5X 

±55! 

YES 

ANGLE  OF  ATTACK 

a 

DEG 

TAEM  & A/L 

-4  TO  +20 

±2° 

YES 
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Table  II.  Orbiter  Air  Data  System  Wind  Tunnel  Program 


MODEL  SCALE 

MATH 

TEST 

ORBITER 

PROBE 

RANGE 

FACILITY 

PURPOSE 

OA-22 

0.03 

None 

0.6  - 1.5 

ARC  11x11,  9x7 

Pressure  survey 

OA-143 

0.03 

None 

0.25 

Rockwell  NAAL 

Pressure  survey 

OA-lOO 

0.36 

0.36, 

FTB 

0.25 

ARC  40x80 

Development 

OA-164 

0.36 

0.36, 

FTB 

0.25 

ARC  40x80 

Development  (Contd.) 

OA174 

0.36 

0.36 

0.25 

ARC  40x80 

Verification 

OA-161A,B,C 

0.03 

None 

0.6  + 3.5 

ARC  11x11,  9x7,  8x7 

Pressure  and  local 
survey 

0A-220 

0.10  (forebody) 

0.20, 

FTB 

0.3  + 1.1 

ARC  14x14 

Development 

OA-224 

0.10  (forebody) 
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SHUTTLE  STRUCTURAL  DYNAMICS  CHARACTERISTICS 
THE  ANALYSIS  AND  VERIFICATION 


C.  Thomas  Modi in,  Jr.,  and  George  A.  Zupp,  Jr 
NASA  Lyndon  B.  Johnson  Space  Center 
Houston,  Texas  77058 


INTRODUCTION 


The  building  and  operation  of  the  Space  Shuttle  represents  a milestone  in  the  U.S.  space  pro- 
gram. The  Shuttle  is  the  first  manned  spacecraft  to  be  reusable;  on  its  first  flight  on  April  12, 
1981,  it  successfully  carried  astronauts  and  a payload  into  Earth  orbit. 

Up  to  this  point  in  space  exploration,  a launch  vehicle  had  to  successfully  complete  an  exten- 
sive and  comprehensive  flight  test  program  before  being  man  rated.  The  Shuttle  program  philosophy, 
on  the  other  hand,  was  to  use  key  element  testing  and  verified  analytical  models  to  certify  the  relia- 
bility of  the  Shuttle  launch  configuration. 

Several  engineering  disciplines  relied  heavily  on  verified  analytical  models  of  the  Space  Shut- 
tle, i.e.,  the  disciplines  of  structural  dynamics,  pogo,  and  flutter.  The  verification  of  these 
models  employed  laboratory  control  testing  to  develop  data  critical  to  math  model  verification.  The 
basic  philosophy  was  to  correlate  analysis  and  testing  to  an  acceptable  degree  of  accuracy  and  infer 
from  this  that  the  launch  vehicle  dynamics  could  be  predicted  with  the  same  accuracy. 

During  the  phase  B period  of  the  program,  analytical  studies  pointed  up  unique  dynamic  character- 
istics of  the  parallel  burn  conf iguration,  in  particular,  a very  high  modal  density  with  200  struc- 
tural modes  below  20  hertz  in  combination  with  a wide  spectrum  of  conditions  involving  a wide  variety 
of  dynamic  problems  (fig.  1).  Studies  conducted  at  the  NASA  Langley  Research  Center  (LaRC)  on  a 
1/8-scale  dynamic  model  reinforced  these  concerns,  and  the  results  indicated  the  substantial  influ- 
ence of  element  interface  stiffness  on  the  primary  low  frequency  modes  of  the  system. 

Immediately  after  approval  to  proceed  with  the  Shuttle,  particular  emphasis  was  placed  on 
developing  a technical  plan  of  action  that  would  ensure  early  resolution  of  the  key  issues  in  the 
structural  dynamics  area.  The  testing  portion  of  the  verification  plan  that  evolved  consisted  of 
three  major  parts:  the  1/4-scale  dynamics  model  program  to  provide  early  data,  tests  of  full- 

scale  elements,  and  a full-scale  mated  vertical  ground  vibration  test  (fig.  2).  In  the  development 
of  the  1/4-Scale  Model  Program,  emphasis  was  placed  on  investigating  enough  propellant  conditions 
to  adequately  represent  the  flight  configurations  from  lift-off  to  end  burn  and  to  minimize  the 
requirements  for  full-scale  testing. 

Further  attention  was  directed  toward  planning  analytical  activities  to  support  hardware  develop- 
ment and  ground  testing.  User  requirements  for  structural  loads,  flight  control,  pogo,  and  flutter 
were  identified  and,  where  required,  specific  models  were  generated  to  meet  the  discipline's  need. 

The  plan  established  the  mechanics  for  generating  and  updating  the  structural  dynamic  math 
models.  Each  element  contractor  was  responsible  for  generating  and  updating  the  models  of  his 
elements,  and  the  system  contractor  was  responsible  for  identifying  requirements  to  the  element 
contractor  and  for  integrating  the  complete  model.  The  objective  of  this  system  was  to  require 
each  contractor  to  be  responsible  for  the  element-unique  models  and  their  verification.  Schedules 
were  established  for  the  development  of  the  structural  math  models  to  support  the  Shuttle  program 
milestones,  the  element  milestones,  and  the  ground  vibration  test  program. 

Extensive  testing  was  also  conducted  to  support  the  verification  of  the  pogo  and  flutter  forcing 
function  models.  Since  each  of  these  disciplines  utilizes  the  structural  dynamic  model,  the  testing 
verification  was  oriented  toward  defining  the  associated  closed-loop  forcing  function.  In  the  case 
of  pogo,  where  pogo  suppressors  on  the  Space  Shuttle  main  engines  (SSME's)  were  baselined  early  in 
the  program,  the  testing  primarily  addressed  the  SSME  dynamics  and  suppressor  characteristics.  This 
was  accomplished  through  the  pulsing  of  the  oxygen  feed  system  to  the  main  engines  and  measuring  the 
attenuation  or  amplification  of  the  pulse  signal  through  the  system.  From  these  data,  the  system 
characteristics  were  extracted  and  used  in  the  pogo  stability  analysis.  The  flutter  models  were 
verified  using  the  same  philosophy.  Flutter  testing  was  extensive,  using  wind  tunnel  testing  with 
aeroelastically  scaled  models. 

The  final  verification  procedures  of  these  models  did  require  an  assessment  of  flight  data,  with 
the  bulk  of  these  data  being  developed  from  STS-1  to  STS-5.  Approximately  a thousand  developed 
flight  measurements  were  involved. 
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FIGURE  1.-  SPECTRUM  OF  SHUTTLE  DYNAMIC  CONFIGURATIONS. 


STRUCTURAL  DYNAMICS 


The  Space  Shuttle  introduced  a new  dimension  in  the  complexity  of  the  structural  dynamics  of  a 
space  vehicle.  The  four-body  configuration  exhibited  structural  frequencies  as  low  as  2 hertz  with 
a model  density  on  the  order  of  10  modes  per  hertz. 

The  structural  dynamic  mathematical  models  are  derived  from  the  "stress  model,"  which  is  a de- 
tailed finite-element  model  of  the  Space  Shuttle  structure.  The  stress  model  has  approximately  5°  000 
degrees  of  freedom  (fig.  3).  The  dynamic  models  were  derived  from  the  stress  model  by  various  re- 
duction techniques,  and  each  has  on  the  order  of  1000  degrees  of  freedom. 

The  degrees  of  freedom  that  are  retained  in  the  dynamic  models  are  designed  to  satisfy  user 
requirements,  i.e.,  disciplines  such  as  pogo,  dynamic  loads,  flutter,  and  flight  control.  For  exam- 
ple, in  the  pogo  structural  models,  a finer  grid  is  retained  in  the  Orbiter  thrust  structure  and  in 
the  liquid  oxygen  (L0X)  feed  system.  Since  the  hydrodynamics  of  the  propellant  are  important  to  the 
pogo  stability  analysis,  a hydroelastic  model  of  the  external  tank  (ET)  is  employed.  Similar  fidel- 
ity is  preserved  in  critical  areas  of  the  vehicle  as  defined  by  the  disciplines  of  dynamic  loads, 
flutter,  and  flight  control. 

One  prime  driver  in  the  degree  of  reduction  of  the  model  is  the  economy  of  computer  operation. 

By  virtue  of  the  limits  on  computer  size  and  speed,  the  eigen  solutions  of  the  reduced  model  will  be 
small  in  comparison  to  the  stress  model.  Therefore,  it  is  of  paramount  importance  that  the  frequencies 
and  mode  shape  that  are  critical  to  the  user  are  preserved  to  an  acceptable  accuracy  during  the  re- 
duction process. 

In  the  verification  process,  certain  mode  shapes  and  frequencies  were  identified  by  the  users  as 
more  important  than  others  and,  as  such,  the  test  objectives  were  oriented  toward  experimentally 
extracting  those  modes  and  frequencies  for  analysis  and  test  correlation  purposes.  To  provide  the 
necessary  experimental  data,  a series  of  ground  vibration  tests  (GVT's)  was  conducted  using  test  arti- 
cles ranging  from  the  1/4-scale  structural  replica  of  the  Space  Shuttle  to  the  full-scale  vehicle. 
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• EXAMPLE  -VERIFICATION  OF  SHUTTLE  STRUCTURAL 
DYNAMIC  CHARACTERISTICS  USED  IN 
DYNAMIC  STABILITY  AND  LOADS  ANALYSES 
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FIGURE  2.-  "BUILDING  BLOCK"  APPROACH  TO  AN  UNDERSTANDING  OF  SHUTTLE  STRUCTURAL  DYNAMICS. 


FIGURE  3.-  OVERALL  VIEW  OF  STRESS  FINITE-ELEMENT  MODEL. 
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GROUND  VIBRATION  TESTING 


The  Space  Shuttle  GVT  program  was  designed  to  provide  structural  dynamic  data  early  in  the  pro- 
gram so  that  if  problems  did  occur,  the  solutions  could  be  implemented  with  a minimum  of  program  cost 
and  schedule  impact.  The  Langley  Research  Center  was  the  first  to  start  a vibration  test  program 
using  a 1/8-scale  structural  model  (refs.  1 and  2).  Although  the  model  replication  was  coarse,  the 
overall  configuration  was  representative  of  the  Space  Shuttle.  The  early  LaRC  data  indicated  the 
presence  of  low  frequency  structural  modes  associated  with  the  four-body  configuration  and  the  impor- 
tance of  the  interface  stiffness  on  these  modes.  Also  of  concern  was  the  lack  of  a verified  analysis 
of  the  ET  hydroelastic  characteristics. 


To  develop  the  necessary  experimental  data  for  math  model  verification,  three  basic  GVT  pro- 
grams were  baselined  in  the  Shuttle  development  schedule.  These  were  the  horizontal  ground  vibration 
test  (HGVT),  the  1/4-scale  model  GVT,  and  the  mated  vertical  ground  vibration  test  (MVGVT) . The  test 
and  analysis  schedule  spanned  the  years  from  1974  to  1981  (fig.  4). 


In  all  major  GVT  programs,  shakers  were  used  to  excite  the  structure  and  accelerometers  were 
used  to  measure  the  structural  response.  A system  known  as  the  Shuttle  Modal  Test  and  Analysis  Sys- 
tem (SMTAS)  was  used  to  control  and  process  the  test  data.  The  excitation  was  in  the  form  of  sine 
dwells,  and  sine  sweeps.  The  frequency  range  of  excitation  was  from  1.5  to  50  hertz.  The  test  arti- 
cles were  usually  instrumented  with  more  than  300  accelerometers,  of  which  about  60  accelerometer 
channels  would  be  processed  simultaneously  during  a dwell  period.  The  vehicle  instrumentation  philos- 
ophy assumed  that  the  vehicle  was  symmetric  about  the  longitudinal  axis,  and,  as  such,  the  modal  ex- 
traction would  be  either  a symmetric  or  an  antisymmetric  mode.  In  selected  cases,  asymmetric  modes 
were  extracted.  The  test  system,  SMTAS,  has  an  illustrative  feature  that  computes  the  orthogonality 
between  a test  mode  and  an  analytical  mode.  The  mass  matrix,  [m],  in  this  calculation  was  derived 
from.  the  analytical  modeland  reduced  to  the  appropriate  accelerometer  grid  locations.  The  test, 
(Ptest*  and  analysis,  (panalysis*  mode  shapes  were  normalized  in  such  a manner  that  for  a perfect 
mode  shape  correlation 


[ m ] 


analysis 


1 


This  feature  gives  a quantitative  measure  of  the  quality  of  the  mode  shape  comparison  between  test 
and  analysis.  Judgment  has  to  be  exercised  in  the  interpretation  of  the  cross  orthogonality  calcula- 
tion because  of  inherent  error  due  to  coarse  gridding  and  reduction  of  the  mass  matrix  to  the  test 
grid  location. 
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FIGURE  4.-  CHRONOLOGY  OF  THE  SHUTTLE  STRUCTURAL  MATH  MODEL  AND  GROUND  VIBRATION  TESTS. 
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HOR I ZONTAL  GROUND  VIBRATION  TEST 


The  HGVT  article  was  the  Orbiter  101  (0V-101)  vehicle  (the  Orbiter  used  in  the  Approach  and  Land- 
ing Test  (ALT)).  These  tests  were  conducted  in  the  summer  of  1976  at  Palmdale,  California.  This  was 
the  first  opportunity  to  get  quality  structural  dynamic  data  for  math  model  verification.  Although 
0V- 101  was  not  identical  to  the  Orbiter  102  (0V-102)  vehicle  (the  Orbiter  used  in  the  first  Shuttle 
launch),  the  differences  were  accounted  for  in  the  structural  math  model.  The  primary  differences 
were  in  the  areas  of  the  OMS  pod  (0V-101  did  not  have  OMS  pods  but  these  were  simulated  by  a "boiler- 
plate" cover),  the  thrust  structure  (the  thrust  structure  was  not  boron  epoxy  as  it  was  in  the  case 
of  0V-102) , and  the  vertical  fin  (the  vertical  fin  was  made  up  of  a skin  and  stringer  configuration 
vs.  integrally  machined  for  the  0V-102  flight  vehicle).  The  payload  in  the  Orbiter  during  testing 
was  the  Development  Flight  Instrumentation  (DFI)  package,  which  weighed  approximately  10  000  pounds. 

There  were  two  basic  test  configurations:  the  Orbiter  supported  in  a "free-free"  condition  to 

simulate  the  entry  and  landing  configurations,  and  the  Orbiter  rigidly  attached  to  the  ground  at  the 
ET/Orbiter  interface  to  simulate  the  boost  configuration  (figs.  5 and  6).  Ferry  locks  also  secured 
the  control  surfaces  during  testing.  The  test  objectives  were  to  determine  experimentally  selected 
mode  shapes,  frequencies,  and  modal  damping  in  the  frequency  range  from  0.5  to  50  hertz,  and  to  ac- 
quire frequency  response  data  at  the  Orbiter  guidance  and  control  sensor  locations.  Table  1 is  a 
comparison  of  analysis  frequencies  and  test  frequencies  for  the  free-free,  or  soft  mount,  configura- 
tion. As  the  analysis  indicates,  the  structural  mode  shapes  are  quite  complicated  and  are  not  gener- 
ally amenable  to  classic  descriptions,  but  the  modal  descriptions  noted  in  table  1 are  the  areas  of 
primary  motion  in  the  noted  mode. 

The  major  results  from  these  tests  were  (1)  the  identity  of  friction  in  the  payload  bay  door 
shear  pins,  which  had  the  effect  of  increasing  the  pitch  bending  stiffness  of  the  fuselage,  (2)  the 
modal  damping,  and  (3)  the  lack  of  analytical  correlation  of  the  center-mounted  rate  gyros  on  the 
1307  bulkhead.  The  modal  damping  data  extracted  from  these  tests  were  invaluable  to  flight  control- 
lers in  the  final  verification  of  the  entry  flight  control  stability  assessment.  For  a detailed  com- 
parison between  test  and  analysis,  refer  to  reference  3. 


FIGURE  5.-  SOFT  HORIZONTAL  GROUND  VIBRATION  TEST 
ARRANGEMENT. 


FIGURE  6.-  RIGID  HORIZONTAL  GROUND  VIBRATION  TEST 
ARRANGEMENT. 


TABLE  1.-  COMPARISON  OF  TEST  AND  ANALYSIS  FREQUENCIES  FOR  THE  FREE-FREE, 
OR  SOFT  MOUNT,  HGVT  (10k  PAYLOAD) 


Modal  description 

Analytical  frequency. 

Test  frequency. 

Hz 

Hz 

First  fuselage  bending  (X-Y  plane) 

5.09 

5.97 

First  wing  bending  (Y-Z  plane) 

7.86 

7.31 

First  vertical  fin  bending  (Y-Z  plane) 

4.15 

3.80 

First  vertical  fin  torsions 

17.20 

14.27 
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QUARTER- SCALE  STRUCTURAL  MODEL 


The  1/4-scale  model  program  was  started  in  early  1975  for  the  purpose  of  developing  high-quality 
structural  dynamic  data  early  in  the  Shuttle  program  that  would  be  representative  of  the  first  Shut- 
tle flight  configuration.  The  structural  model  was  a high-fidelity  replication  of  0V-102,  the  stand- 
ard ET,  and  three  flight  configurations  of  the  solid  rocket  booster  (SRB)  (ref.  4).  The  1/4-scale 
program  was  the  most  comprehensive  element  in  the  Shuttle  GVT  program.  Of  the  test  articles  used  in 
the  vibration  test  program , the  1/4-scale  model  was  structured  most  like  the  flight  hardware. 

The  1/4-scale  vibration  test  configuration  included  the  following. 

1.  Orbiter/ET/SRB  configuration  (with  45^  "rigid"  payload) 

a.  Lift-off 

b.  Maximum  dynamic  pressure 

c.  Pre-SRB  separation 

2.  Orbiter/ET  configuration  (with  45^  "rigid"  payload) 

a.  Start  boost 

b.  Mid  boost 

c.  End  boost 

3.  Orbiter  element  (with  and  without  45k  "rigid"  payload) 

4.  ET  element,  13°  tilt 

5.  SRB  element 

During  testing,  water  was  used  to  simulate  the  LOX  in  the  ET  and  the  weight  and  hydroelastic  effects 
of  the  liquid  hydrogen  (LH)  in  the  hydrogen  tank  were  neglected.  This  procedure  was  also  used  in 
the  MVGVT. 

To  complement  the  vibration  test  program,  load-deflection  tests  were  conducted  on  the  SRB  and 
the  ET.  The  load-deflected  tests  were  designed  to  provide  data  that  could  be  used  to  resolve  anoma- 
lous or  unexplained  vibration  test  data.  Primarily,  the  load-deflection  data  supported  the  verifica- 
tion of  the  stiffness  matrix  in  the  idealized  structural  model. 

At  the  start  of  the  1/4-scale  program,  there  were  several  areas  that  presented  problems  in  struc- 
tural dynamic  modeling.  These  were  the  ET  hydroelastic  analysis,  the  interface  stiffnesses  between 
the  elements,  the  SRB  propellant  and  internal  pressure  effects  on  the  system  structural  modes,  and 
the  payload  bay  door  effectivity  in  the  Orbiter  fuselage  pitch  bending  stiffness. 

Because  of  the  pogo  requirements  for  a high-fidelity  hydroelastic  analysis,  the  hydroelastic 
model  of  the  ET  was  of  particular  concern  in  the  early  stages  of  the  program.  The  lack  of  correla- 
tion between  test  and  analysis  with  LaRC  data  indicated  that  the  same  deficiency  could  be  expected 
from  the  hydroelastic  analysis  of  the  ET;  therefore,  several  1/4-scale  tank  configurations  were 
selected  for  testing.  In  parallel,  the  Martin  Marietta  Company  was  developing  a new  hydroelastic 
analysis  which  became  available  before  1/4-scale  testing.  The  quality  of  correlation  between  the 
upgraded  hydroelastic  analysis  and  the  ET  vibration  data  was  judged  excellent  and  provided  the  confi- 
dence in  the  analysis  that  allowed  a reduction  in  scope  of  the  ET  vibration  testing.  Generally,  the 
analysis  frequencies  were  higher  than  the  test  frequencies.  These  differences  were  attributed  to  in- 
ternal pressure  effects  in  the  LOX  tank  and  the  LH  tank. 

The  Orbiter  test  verified  the  presence  of  friction  in  the  payload  bay  door  shear  pin  sufficient 
to  effectively  increase  the  pitch  bending  stiffness  at  low  excitation  levels.  This  increase  in 
stiffness  increased  the  bending  frequency  above  that  of  the  predicted  value.  The  use  of  higher  exci- 
tation forces  on  the  structure  overcame  the  friction  in  the  shear  pins  and  thereby  allowed  relative 
motion  between  the  door  bays  and  consequent  reduction  of  the  bending  stiffness  and  frequency.  The  re- 
duction in  frequency  was  consistent  with  pretest  analysis. 

Several  Orbiter  configurations  were  tested  that  addressed  the  effects  of  payload  weight  on  the 
Orbiter  vibration  characteristics.  Ground  vibration  tests  were  also  conducted  with  payload  bay  doors 
opened  to  simulate  the  on-orbit  configuration. 

The  SRB  tests  identified  several  areas  in  the  math  model  that  required  additional  study.  These 
were  (1)  the  ET/SRB  interface,  which  required  additional  detail  in  the  finite-element  model,  (2)  the 
incorporation  of  a representative  shear  modulus  for  the  propellant,  and  (3)  the  incorporation  of  the 
internal  pressure  effects  on  shell  stiffness.  The  posttest  analysis  incorporated  changes  in  the  math 
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model  that  corrected  some  of  these  deficiencies.  The  internal  pressure  effects  on  the  shell  stiff- 
ness were  handled  emperically;  the  shear  stiffness  effects  of  the  propellant  were  still  in  a state 
of  iteration  at  the  time  of  MVGVT.  Comparisons  of  the  test  and  analysis  frequencies  for  the  Orbiter 
test  and  the  Orbiter/ET/SRB  lift-off  test  are  presented  in  tables  2 and  3,  respectively.  A detailed 
presentation  of  1/4-scale  model  test  data  and  analysis  can  be  found  in  reference  5. 


TABLE  2.-  COMPARISON  OF  TEST  AND  ANALYSIS  FREQUENCIES  FOR  THE  "FREE-FREE"  1/4-SCALE 

ORBITER  GVT  (45k  PAYLOAD) 


Modal  description  Analytical  frequency.  Test  frequency, 

Hz  Hz 


First  fuselage  bending  (X-Y  plane) 

4.6 

4.8 

First  wing  bending  (Y-Z  plane) 

7.0 

6.6 

First  vertical  fin  bending  (Y-Z  plane) 

3.9 

3.6 

First  vertical  fin  torsion 

14.0 

12.8 

TABLE  3.-  COMPARISON  OF  TEST  AND  ANALYSIS  FREQUENCIES  FOR  THE  "FREE-FREE' 

" 1/4-SCALE 

ORBITER/ET/SRB  LIFT-OFF  CONFIGURATION  (45k  PAYLOAD) 

Modal  description 

Analytical  frequency.  Test  frequency, 

Hz 

Hz 

SRB  roll  (antisymmetric) 

2.0 

1.8 

SRB  roll  (antisymmetric) 

2.0 

2.0 

First  vertical  fin  bending  (Y-Z  plane) 

3.7 

3.4 

First  wing  bending  (X-Z  plane) 

6.3 

6.4 

MATED  VERTICAL  GROUND  VIBRATION  TEST 


The  MVGVT  was  the  final  major  test  program  in  the  structural  dynamic  model  verification  plan. 
These  tests  were  conducted  between  the  summers  of  1978  and  1979  at  the  NASA  George  C.  Marshall 
Space  Flight  Center  (MSFC)  in  Huntsville,  Ala.  The  primary  objectives  of  these  tests  were  to 
experimentally  obtain  full-scale  structural  mode  shapes,  frequencies,  damping  data,  and  transfer 
functions  at  selected  flight  control  sensor  locations.  The  test  configurations  (figs.  7 and  8) 
were  as  follows. 

1.  Orbiter/ET/SRB  configuration  (payload  10k) 

a.  Lift-off 

b.  Pre-SRB  separation 

2.  Orbiter/ET  configuration  (payload  10k) 

a.  Start  boost 

b.  Mid  boost 

c.  End  boost 

The  modal  data  extracted  from  these  tests  compared  favorably  with  the  modal  data  derived  from 
1/4-scale  model  testing  when  the  known  configuration  differences  were  considered.  Presented  in  table 
4 is  a comparison  between  test  and  analysis  frequencies  and  the  associated  modal  damping  presented  as 
percent  of  critical  damping  for  the  MVGVT  lift-off  configuration. 

The  major  result  of  these  tests  was  the  identification  of  local  resonances  in  the  area  of  the 
SRB  rate  gyro  locations.  These  resonances  had  the  effect  of  corrupting  the  sensor  signals,  which,  if 
occurring  in  flight,  would  have  the  effect  of  a lost  sensor.  Other  anomalies  were  also  noted  on  the 
Orbiter  side-mounted  rate  gyros. 

The  issue  raised  during  1/4-scale  testing  concerning  SRB  propellant  stiffness  was  not  resolved. 
Because  of  the  nonlinear  viscoelastic  properties  of  the  SRB  propellant,  the  eventual  resolution  of 
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FIGURE  7.-  SUSPENSION  SYSTEM  FOR  THE  SPACE  SHUTTLE  (FOUR-BODY  CONFIGURATION). 


this  problem  was  through  adjusting  the  analysis  via  the  propellant  shear  stiffness  to  agree  with  test 
data.  Fortunately  for  the  users  of  the  structural  dynamic  models,  the  structural  modes  with  signifi- 
cant SRB  propellant  motion  had  relative  high  damping  and  were  not  significant  in  the  performance  of 
the  various  user  disciplines. 

The  structural  damping  data  extracted  from  these  tests  ranged  from  a low  of  about  0.1  percent 
for  the  modes  with  significant  fluid  motion  to  more  than  10  percent  for  certain  "local"  modes.  The 
average  modal  damping  ranged  from  1 to  3 percent.  The  damping  data  were  extremely  valuable  in  the 
final  certification  of  the  flight  control  stability  margins  in  that  measured  damping  values  in  the 
critical  flight  control  modes  were  higher  than  the  initial  baseline  of  0.5  percent. 
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TABLE  4.-  COMPARISON  OF  TEST  AND  ANALYSIS  FREQUENCIES  FOR  THE  "FREE-FREE"  MVGVT 
LIFT-OFF  CONFIGURATION  (10k  PAYLOAD) 


Modal  description 

Analytical  frequency, 
Hz 

Test  frequency, 
Hz 

Damping 

c/cc 

SRB  roll  (antisymmetric) 

1.88 

2.08 

0.01 

SRB  roll  (symmetric) 

1.90 

2.05 

.013 

First  Orbiter  bending  (Y-Z  plane) 

2.97 

3.24 

.01 

First  wing  bending  (Y-Z  plane) 

6.70 

6.43 

.037 

SUMMARY 

The  advent  of  the  Space  Shuttle  presented  unique  challenges  to  the  structural  dynamics  analyst 
in  the  sense  that  the  analytical  models  had  to  be  verified  to  an  acceptable  accuracy  before  a manned 
launch.  This  objective  was  accomplished  in  the  Shuttle  program  by  an  extensive  vibration  test  anal- 
ysis program.  The  three  main  vibration  test  programs  were  HGVT,  1/4-scale  model  GVT,  and  the  MVGVT. 
Significant  analytical  effort  was  committed  to  modeling  the  test  configuration.  The  correlation  of 
these  results  provided  a foundation  for  model  certification. 

The  structural  dynamic  model  used  provided  an  invaluable  input  into  the  certification  process  by 
defining  the  structural  dynamic  elements  and  modes  that  were  critical  to  the  discipline  analysis. 

For  example,  to  improve  the  accuracy  of  predicting  the  dynamic  response  of  Orbiter  payloads  during 
landing  and  lift-off,  increased  fidelity  in  the  modeling  of  the  Orbiter  longerons  and  payload 
interfaces  was  required. 
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Generally,  the  vibration  test  and  analysis  program  revealed  that  the  mode  shapes  and  frequency 
correlations  below  10  hertz  were  good.  The  quality  of  correlation  of  modes  between  10  and  20  hertz 
ranged  from  good  to  fair  and  that  of  modes  above  20  hertz  ranged  from  poor  to  good.  Since  the  most 
important  modes,  based  on  user  preference,  were  below  10  hertz,  it  was  judged  that  the  Shuttle  struc- 
tural dynamic  models  were  adequate  for  flight  certifications. 
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ABSTRACT 


The  challenges  that  resulted  from  the  unique  configuration  of  the  Space  Shuttle  and  capabil- 
ities developed  to  meet  these  challenges  are  described.  Discussed  are  the  methods  and  the  organiza- 
tion that  were  developed  to  perform  dynamic  loads  analyses  on  the  Space  Shuttle  configuration  and  to 
assess  dynamic  data  developed  after  design.  Examples  are  presented  from  the  dynamic  loads  analysis 
of  the  lift-off  and  maximum  dynamic  pressure  portion  of  ascent.  Also  shown  are  Orbital  Flight 
Test  results,  for  which  selected  predicted  responses  are  compared  to  measured  data  for  the  lift- 
off and  high-dynamic-pressure  times’  of  ascent. 


INTRODUCTION 

The  challenge  of  the  Space  Shuttle  was  to  develop  a system  which  had  optimum  structural  weight, 
structural  integrity,  and  the  operational  flexibility  to  carry  a wide  variety  of  payloads  to  Earth 
orbit.  The  Space  Shuttle  structural  system,  which  had  a unique  combination  of  configuration,  en- 
vironments, and  operating  procedures,  represented  the  greatest  challenge  to  the  dynamic  loads  ana- 
lyst in  the  history  of  space  vehicle  design.  This  configuration  had  four  bodies  connected  in  paral- 
lel, whereas  all  previous  space  vehicle  configurations  were  axi symmetric  (sometimes  with  strapped-on 
motors).  The  Orbiter  had  wings  and  a vertical  tail,  whereas  no  previous  configurations  had  aero- 
dynamic surfaces.  Three  of  the  four  bodies  had  thrust  forces  in  the  millions  of  pounds.  The  winged 
Orbiter  configuration  and  the  proximity  of  the  external  tank  (ET)  and  the  solid  rocket  boosters  (SRB's) 
resulted  in  complex  and  difficult  to  define  forces  and  pressure  distributions  on  all  of  the  bodies, 
whereas  previous  space  vehicles  had  the  relatively  clean  aerodynamic  configuration  of  an  axi symmetric 
vehicle.  The  structure  that  connected  the  elements  of  the  Shuttle  was  very  sensitive  to  the  external 
forces  applied  to  any  element.  A small  change  in  aerodynamic  force  or  a small  change  in  thrust  or 
thrust  direction  was  magnified  into  a large  percentage  of  change  in  the  interface  struts  and  backup 
structure.  Therefore,  during  all  ascent  loading,  balance  had  to  be  maintained  between  the  vehicle  el- 
ements during  periods  of  transient  thrust,  such  as  lift-off,  and  during  the  period  of  high  aerodynamic 
loading. 

To  meet  the  challenge  of  developing  a structural  system  that  would  meet  the  Space  Shuttle  pro- 
gram overall  goals,  new  capability  had  to  be  established  in  both  the  analytical  and  organizational 
areas.  In  the  analytical  area,  the  capability  to  evaluate  the  variables  that  would  affect  the  vehi- 
cle loading  and  response  was  required.  Typical  of  these  variables  are  thrust  and  thrust  transients, 
winds  and  gusts,  and  mass  variations.  Analytical  tools  had  to  be  developed  to  assess  each  effect 
that  could  contribute  to  the  vehicle  loading.  In  addition,  lines  of  communication  had  to  be  es- 
tablished between  the  structural  loads  analysis  community  and  each  group  or  organization  that  had 
the  responsibility  for  definition  of  all  effects  that  should  be  considered  in  the  dynamic  loads 
analysis. 

The  interactions  among  vehicle  systems  and  environmental  effects  are  shown  schematically  in  fig- 
ure 1.  The  flow  of  design  data  for  vehicle  structural  design  is  shown  by  the  arrows.  In  some  cases, 
the  events  or  effects  from  the  different  disciplines  can  interact  and  result  in  changes  from  the  orig- 
inal definition  of  the  effect.  The  Space  Shuttle  design  conditions  included  all  significant  loading 
events.  These  were  prelaunch,  lift-off,  maximum  dynamic  pressure,  maximum  load  factor  during  SRB 
boost,  SRB  staging,  and  Orbiter/ET  ascent  with  Space  Shuttle  main  engine  (SSME)  burn. 

In  this  paper,  two  analysis  conditions  that  presented  the  greatest  challenge  to  the  vehicle 
loads  and  dynamic  analyst  are  discussed.  The  first  is  the  lift-off  event,  which  was  chosen  because 
of  its  extremely  transient  nature  in  which  engine  ignitions,  overpressure  waves,  release  of  holddown 
constraints,  and  winds  must  all  be  considered.  The  second  is  the  hi gh-dynamic-pressure  (high  q)  re- 
gion of  ascent.  It  is  chosen  because  of  the  complexity  of  the  aerodynamic  environment  and  the  con- 
cept developed  to  define  high-q  loading  conditions  for  vehicle  design.  Other  conditions,  such  as 
staging,  that  have  been  so  important  in  transient  loads  analysis  in  previous  space  vehicle  designs 
are  quite  benign  for  the  Space  Shuttle  and  will  not  be  addressed  here. 
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FIGURE  1.-  VEHICLE  SYSTEMS  AND  ENVIRONMENT  INTERACTIONS. 
LIFT-OFF 


The  lift-off  event,  because  of  its  extremely  transient  nature,  represented  the  greatest  challenge 
to  the  analyst  in  predicting  the  overall  elastic-body  dynamic  response  of  the  Space  Shuttle.  The  ef- 
fects that  were  of  greatest  concern  were  the  ability  to  simulate  the  SSME  and  SRB  ignition  character- 
istics and  the  longitudinal  expansion  of  the  SRB  motor  case,  accurate  inclusion  of  the  SRB  ignition 
overpressure  environment,  and  the  physically  accurate  simulation  of  the  constraint  force  release  be- 
tween the  vehicle  and  the  launch  facility. 

Developing  the  capability  to  make  realistic  predictions  of  vehicle  lift-off  loads  and  to  satisfy 
all  the  pre-analysis  concerns  was  the  challenge.  Three  areas  of  development  had  to  be  completed  for 
a prediction  of  lift-off  loads  for  design  or  design  certification.  These  were: 

1.  Development  of  a structural  dynamic  mathematical  model 

2.  Development  and  definition  of  the  variables  or  the  effects  significant  to  the  lift-off  event 

3.  Development  of  the  structural  design  criteria  and  load  analysis  procedures 


SPACE  SHUTTLE  STRUCTURAL  DYNAMIC  MATHEMATICAL  MODEL 


The  Space  Shuttle  structural  dynamic  mathematical  model  development  presented  several 
challenges.  These  were: 

1.  The  coupling  of  four  large  bodies  and  payloads  into  the  math  model 


336 


2.  Accounting  for  temperature  effects  on  the  stiffness  characteristics  of  the  solid  rocket 
motor  propellant 

3.  Consideration  of  pressurized  and  nonpressurized  SRB's 

4.  Requirement  for  many  degrees  of  freedom  in  the  model,  typically  in  the  range  of  1000 
(Previous  space  vehicles  had  degrees  of  freedom  in  the  range  of  500.) 

A comprehensive  discussion  of  math  model  development  is  given  in  reference  1. 

EFFECTS  SIGNIFICANT  TO  THE  LIFT-OFF  EVENT 

The  number  of  effects  and  their  variations  that  were  significant  contributors  to  the  analysis 
of  lift-off  are  as  follows. 

1.  Structural  dynamic  mathematical  model 

a.  SRB  propellant  stiffness  (hot  or  cold) 

b.  Effects  of  external  tank  cryogenic- induced  shrinkage  (preloads  at  base) 

2.  SSME  thrust  characteristics 

a.  Buildup  rate  (fast  or  slow) 

b.  Thrust  misalinement  (±pitch,  troll,  tyaw) 

c.  Dispersion  on  start  time  (simultaneous  or  333-millisecond  delay) 

d.  Ignition  overpressure 

e.  Failure  case  (loss  of  thrust  on  one  SSME) 

3.  SRB  thrust  characteristics 

a.  Buildup  rate 

b.  Thrust  level  (high  or  low  performance) 

c.  Mismatch  (synmetrlc  or  unsynmetrlc  thrust  buildup) 

d.  Thrust  misalinement  (Inboard,  outboard,  tpitch,  ±>aw,  troll) 

e.  Ignition  overpressure  (magnitude,  frequency,  and  timing) 

4.  Winds 

a.  Direction  and  speed 

b.  Gust  wave  length  and  timing 

c.  Asymmetric  vortex-shedding 

5.  Timing  of  events  - Nominal  timing  and  dispersions 

6.  Sudden  release  of  reaction  forces  at  vehicle  base 

The  challenge  in  properly  assessing  these  effects  was  getting  each  effect  defined  in  a manner  which 
was  applicable  to  the  structural  load  analysis  and  combining  the  effects  to  define  a structural  limit 
load  for  the  lift-off  event. 


STRUCTURAL  DESIGN  CRITERIA  AND  LOAD  ANALYSIS  PROCEDURES 


The  lift-off  dynamic  loads  event  that  is  initiated  with  the  start  of  the  SSME’s  Is  shown  schemat- 
ically in  figure  2.  This  event  involves  the  general  dynamic  response  of  the  Space  Shuttle  when 
attached  to  the  mobile  launch  platform  (MLP)  and  when  free  from  the  MLP.  The  challenge  to  the  struc- 
tural loads  analyst  is  to  evaluate  this  sequence  of  events  for  structural  loading.  Shown  in  figure 


337 


REACTIONS  AT 
LAUNCH  PAD 

fz  fi*  my 


VEHICLE  PRIOR  TO  SRB  IGNITION  SIGNAL 
1.  APPLIED  FORCES 


WIND 


SSME  THRUST  BUILD-UP 
WINDS  AND  GUSTS 

2.  BASE  REACTIONS 

Fz  HORIZONTAL  FORCE 
MY  MOMENT 


SSME  THRUST 


FIGURE  2.-  LIFT-OFF  SEQUENCE. 


FIGURE  3.-  LIFT-OFF  CONFIGURATION  AND  APPLIED 
FORCES. 


3 is  the  Space  Shuttle  and  the  external  forces  acting  on  the  vehicle  just  before  SRB  ignition  and 
holddown  release.  The  effects  that  are  applied  in  the  lift-off  simulations  are  combined  to  yield  an 
engineering  approximation  of  an  overall  3o  event. 

The  SSME  engines  are  ignited  and  build  up  to  100  percent  of  rated  power  level.  The  design-level 
winds,  including  gusts,  are  applied.  When  all  three  engines  are  at  90  percent  thrust  or  greater,  a 
signal  is  given  to  ignite  the  SRB's  and  release  the  vehicle.  Before  release,  the  horizontal  forces 
and  overturning  moments  are  reacted  at  the  base  of  the  vehicle  by  the  launch  pad.  At  the  time  of  re- 
lease, a significant  moment  has  built  up  at  the  base  of  each  SRB  to  counteract  the  wind  and  SSME 
forces.  In  figure  4,  the  left  side  shows  the  deflected  shape  of  the  SRB's  just  before  release,  and 
the  middle  shows  the  deflected  shape  just  after  lift-off.  The  forces  at  the  base  of  the  SRB's  decay 
rapidly  to  zero  at  the  time  of  lift-off  since  there  are  no  reacting  forces  once  the  vehicle  leaves 
the  pad.  This  rapid  decay  of  base  forces  and  change  in  deflected  shape  represents  a shock  input  to 
the  structure.  The  shock  excites,  or  "twangs,"  the  vehicle  and  causes  it  to  vibrate  significantly, 
mainly  in  its  lower  frequency  structural  modes.  The  right  side  of  figure  4 shows  a time  history  of 
the  base  moment. 

An  update  to  the  lift-off  analysis  data  base  was  conducted  in  1977  in  support  of  the  Shuttle 
critical  design  review.  This  analysis  resulted  in  a marked  increase  in  dynamic  loads,  notably  in  the 
region  of  the  Orbiter/ET  forward  attachment  structure.  Although  the  analysis  included  updates  to  all 
areas  of  the  data  base,  the  increase  in  dynamic  loads  was  primarily  attributed  to  refinements  in  the 
stiffness  characterization  of  the  SRB's.  Changes  were  made  in  the  treatment  of  the  stiffness  prop- 
erties of  the  solid  propellant  and  in  the  stiffening  effect  of  internal  pressure.  Among  the  meas- 
ures considered  to  alleviate  the  loads  were: 

1.  Lift-off  with  a lower  thrust  level  on  the  SSME's 

2.  Lift-off  with  one  engine  out 

3.  Tilting  the  vehicle  on  the  launch  pad 

4.  Devising  a controlled  release  for  the  base  restraints 

5.  Introducing  a time  delay  for  SRB  ignition  and  vehicle  release 

A study  of  these  options  showed  that  most  of  them  were  either  ineffective  or  unfeasible,  or  intro- 
duced undesired  risks.  Option  5 proved  to  be  both  effective  and  easy  to  implement. 

A time  history  of  the  base-bending  moment  of  the  vehicle  and  the  time  of  nominal  release  are 
shown  in  figure  5.  It  is  known  that  if  the  magnitude  of  the  base-bending  moment  at  the  time  of  re- 
lease could  be  reduced,  the  subsequent  twang  loads  would  also  be  reduced;  thus,  it  was  proposed  that 
the  time  of  the  lift-off  be  delayed  past  the  time  of  peak  moment  until  the  vehicle  has  rebounded  and 
the  bending  moment  is  in  the  trough.  The  delay  chosen  was  2.7  seconds.  The  effect  of  this  time 
delay  is  to  reduce  the  critical  twang  load  in  the  forward  attachment  structure  by  25  percent.  The  ef- 
fect of  the  SRB  ignition  delay  on  payload  capability  (a  loss  of  600  pounds)  is  considered  acceptable, 
and  the  effect  on  the  acoustic  life  of  the  structure  is  negligible. 
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DEFLECTED  SHAPE  DEFLECTED  SHAPE  BASE  MOMENT 

BEFORE  LIFT-OFF  AFTER  LIFT-OFF  TIME  HISTORY 


TIME  (SEC) 


FIGURE  5.-  DELAYED  SRB  IGNITION  BASE  Mv  VERSUS 
FIGURE  4.-  LIFT-OFF  TWANG  EFFECT.  TIME. 


The  implementation  of  the  2.7-second  SRB  ignition  delay  required  assurance  of  the  ability  to  ac- 
curately predict  the  cantilevered  dynamic  characteristics  of  the  vehicle,  i.e.,  the  time  and  extent 
of  the  rebound.  Full-scale  dynamic  testing  was  conducted  using  SRB's  bolted  to  the  launch  pad. 

Final  verification  was  obtained  from  the  flight  readiness  firing  of  the  Shuttle  engines  before  STS-1. 
Figure  6 is  a time  history  of  the  strain  in  the  tiedown  bolts  between  the  SRB's  and  the  launch  pad. 
This  strain  is  a measure  of  base-bending  moment.  The  predicted  optimum  time  for  lift-off  coincided 
precisely  with  the  time  of  minimum  strain  in  the  bolts.  The  2.7-second  SRB  ignition  delay  is  now 
the  baseline  procedure  in  the  Shuttle  lift-off  sequence. 


HIGH-q  BOOST  - GENERAL  DESCRIPTION 


The  second  ascent  event  presenting  significant  challenges  in  loads  analysis  is  high-q  boost.  As 
shown  in  figure  7,  the  time  of  high  dynamic  pressure  (i.e.,  greater  than  400  psf)  is  approximately  30 
seconds  to  90  seconds  flight  time,  which  corresponds  to  a Mach  number  range  of  0.6  to  2.7.  These 

values  will  vary  from  flight  to  flight,  being  dependent  on  specific  trajectory  design  and  dispersions 

such  as  winds.  Features,  some  new  or  unique,  of  the  high-q  boost  event  are  as  follows: 

1.  Vertical  ascent  through  wind  shears  and  gusts 

2.  Throttling  of  the  three  main  engines  to  as  low  as  65  percent  of  rated  power  to  limit  the 

value  of  maximum  dynamic  pressure 

3.  Movement  of  the  elevons  through  a predetermined  deflection  schedule  to  limit  airloads  on  the 
elevons 


4.  An  active  load- relief  control  system  providing  commands  for  gimbaling  the  three  SSME's  and 
the  two  SRB's  in  response  to  wind  shear  and  gust 
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FIGURE  7.-  TYPICAL  HIGH-q  BOOST  TRAJECTORY  DATA. 


FIGURE  6.-  FLIGHT  READINESS  FIRING  TIEDOWN 
BOLT  STRAIN. 
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HIGH-q  BOOST  LOADS  SURVEY 

In  early  Shuttle  load  studies,  full  dynamic  simulations  were  made  of  the  elastic  vehicle  tran- 
sient response.  Approximately  20  cases  were  run  in  a typical  loads  survey;  however,  it  was  apparent 
that  the  Shuttle  configuration  (i.e.,  winged  vehicle  with  parallel  staging)  made  it  more  sensitive  to 
wind  azimuth  and  system  dispersions  than  was  an  axisymmetric  vehicle  such  as  Apollo/Saturn.  This  dif- 
ference is  illustrated  in  figure  8.  The  structural  loads  survey  considered  dispersions  on  parameters 
such  as: 


1.  SSME  thrust  level  and  thrust  vector  alinement 

2.  SRB  thrust  level  and  thrust  vector  alinement 

3.  SRB  thrust  mismatch 

4.  Trajectory  differences  for  the  various  design  missions 

5.  Variations  in  rotational  accelerations 

6.  Tolerances  in  aerodynamic  coefficients 

7.  Loss  of  thrust  of  any  one  SSME. 

A calculation  technique  was  required  to  provide  a more  rapid  and  cost-effective  means  of  survey- 
ing all  combinations  of  flight  time,  wind  azimuth,  and  systems  dispersions.  Expanded  use  of  full- 
transient-response  simulations  would  be  time-consuming  and  expensive;  thus,  a new  technique  based  on 
the  use  of  weighting  factors  applied  to  unit  sensitivity  load  cases  (load  parti als)  was  devised  to 
identify  the  critical  combinations  of  dispersions.  These  selected  critical  cases  were  then  evaluated 
to  obtain  balanced  distributed  loads. 

The  focus  of  the  load  survey  was  the  q-alpha  versus  q-beta  flight  envelopes  called  "squatch- 
eloids."  The  squatcheloid  provides  a means  of  defining  the  pertinent  flight  dynamics  parameters  such 
as  dynamic. pressure  (q),  angle  of  attack  (alpha),  angle  of  sideslip  (beta),  and  the  rotational  accel- 
erations (p,  q,  and  r).  An  example  is  shown  in  figure  9.  The  inner  A squatcheloid  is  based  on 
nominal  wind  criteria  as  noted.  The  B squatcheloid  is  based  on  the  full  design  wind  criteria;  i.e., 

99  percentile  wind  shear  and  9 m/sec  gust,  reduced  by  a multiplying  factor  of  0.85  to  account  for  a 
statistical  combination  of  shears  and  gusts.  The  A1  squatcheloid  includes  the  effects  of  system  dis- 
persions such  as  thrust  variations  and  accelerometer  alinements.  The  load  increments  between  the  B 
and  A squatcheloi ds  and  between  the  A1  and  A squatcheloids  are  treated  as  dispersions  and  are  combined 
appropri ately  with  other  dispersions  in  the  loads  calculation  process.  Such  a methodical  treatment 
is  necessary  because  of  the  sensitivity  of  the  Shuttle  configuration  to  dispersions  in  vehicle  and  en- 
vironmental data. 


HEADWIND  QUARTERING  HEADWIND 


FIGURE  8.-  CONFIGURATION  DIFFERENCES. 


q/3/IOOO  (PSF-OEQ) 


5/3/1000  (PSF-DEQ) 


FIGURE  9.-  EXAMPLE  OF  SQUATCHELOID  FOR  MACH  1.05. 


340 


Squatcheloids  are  developed  for  each  of  several  Mach  numbers  of  interest  in  the  high-q  regime 
for  both  no-failure  and  one-engine-out  conditions.  The  high-q  loads  analysis  then  becomes  the  method- 
ical survey  of  the  squatcheloids,  including  consideration  of  all  pertinent  deterministic  and  random 
dispersions  in  the  data  base.  The  method  for  handling  dispersions  is  as  follows. 


Lmax  = La  + £ (deterministic  load  increments)  + RSS  (random  load  increments) 


where  Lmax  is  the  maximum  load  for  survey  and  L/\  is  the  baseline  load  (Mission  3;  A squatcheloid) . The 
load  increments  are  defined  as  follows. 

1.  Deterministic  load  increments 

a.  Portion  of  SRB  thrust  dispersion 

b.  Effect  of  SSME  throttling 

c.  Missions  other  than  Mission  3 

2.  Random  load  increments 

a.  SRB  thrust  misalinements 

b.  SRB  thrust  mismatch 

c.  Rotational  acceleration  dispersions 

d.  Elevon  deflection  dispersion 

e.  Effect  of  maximum  wind  shear  and  gust  (squatcheloid  B minus  squatcheloid  A) 

f.  Effect  of  flight  control  dispersions  (squatcheloid  A1  minus  squatcheloid  A) 

g.  Aerodynamic  tolerances 

h.  Portion  of  SRB  thrust  dispersion 

Using  the  load  parti als,  the  effects  of  deterministic  dispersions  are  combined  directly,  whereas 
the  effects  of  random  independent  dispersions  are  combined  by  root  sum  square  (RSS).  The  load  survey 
is  conducted  by  calculating  loads  for  approximately  30  places  on  the  vehicle  including  the  wing,  the 
vertical  tail,  and  the  interface  structures  between  the  Orbiter  and  the  ET,  and  between  the  SRB's  and 
the  ET.  Computer  programs  have  been  developed  for  the  rapid  and  inexpensive  survey  of  load  cases 
using  rigid-body  calculation  techniques.  When  the  critical  cases  have  been  identified,  balanced 
distributed  load  cases  are  developed  including  the  loads  caused  by  elastic-body  response. 

At  the  time  of  the  Shuttle  critical  design  review,  the  methodology  described  was  used  to  survey 
approximately  65  000  load  cases  in  the  high-q  boost  regime.  Of  these,  approximately  50  cases  were 
selected  for  final  distributed  loads.  Figure  10  illustrates  a typical  distribution  of  critical  cases 
on  the  squatcheloids,  wherein  each  data  point  represents  a maximum  load  on  the  wings,  the  vertical 
tail,  or  the  interface  structure.  The  squatcheloid  survey  technique  has  proved  to  be  an  efficient 
method  for  the  survey  of  all  Shuttle  system  dispersions. 


ORBITAL  FLIGHT  TEST  PROGRAM  RESULTS 


In  this  paper,  several  challenges  to  the  structural  load  analysis  discipline  resulting  from  the 
unique  Shuttle  vehicle  configuration  are  discussed.  In  the  case  of  lift-off,  changes  to  the  charac- 
terization of  the  vehicle  dynamic  properties,  SSME  and  SRB  thrust  buildup  data,  and  ignition  over- 
pressure data  all  posed  threats  to  the  structural  design  during  Shuttle  development.  Similarly, 
for  high-q  boost,  updates  to  aerodynamic  characteristics  and  the  advent  of  higher  performance  trajec- 
tories also  had  the  potential  to  impact  the  structural  design.  After  years  of  analysis  and  re-analysis, 
the  final  verification  of  structural  design  load  adequacy  was  to  come  from  data  obtained  during  the 
Orbital  Flight  Test  (OFT)  program.  The  OFT  program  consisted  of  the  first  four  Shuttle  flights,  STS-1 
through  STS-4.  On  these  flights,  as  well  as  on  STS-5,  development  flight  instrumentation  collected 
data  for  the  postflight  reconstruction  of  the  loads.  In  both  lift-off  and  high-q  boost,  there  was 
general  verification  of  the  design  data  base;  however,  some  surprises  also  occurred. 
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LIFT-OFF  FLIGHT  TEST  RESULTS 


The  most  notable  result  pertaining  to  lift-off  occurred  on  STS-1.  The  ignition  overpressure 
wave  from  the  SRB's  was  much  more  severe  than  predicted.  The  resulting  transient  loads  caused  damage 
to  a strut  supporting  a tank  in  the  Orbiter  forward  reaction  control  system.  The  subscale  model  test- 
ing that  had  been  used  to  predict  the  overpressure  environment  was  deficient  in  predicting  the  full- 
scale  pressure  wave.  After  STS-1,  additional  modified  subscale  testing  led  to  modifications  to  the 
launch  pad  to  attenuate  the  overpressure  wave.  These  steps  were  strikingly  successful  in  eliminating 
overpressure  as  a contributor  to  dynamic  loads.  In  all  subsequent  flights  beginning  with  STS-2, 
nominal  lift-off  loads  that  are  well  within  design  limits  have  occurred.  Shown  in  figure  11  are 
examples  of  the  generally  excellent  correlation  between  the  analytical  reconstruction  and  the  meas- 
ured flight  data. 


HIGH-q  BOOST  FLIGHT  TEST  RESULTS 

An  unanticipated  result  during  high-q  boost  also  occurred  on  STS-1.  The  trajectory  was  "lofted"; 
i.e.,  the  flightpath  deviated  from  the  planned  trajectory.  In  postflight  evaluations,  this  phenomenon 
was  attributed  to  a discrepancy  in  the  aerodynamic  data  pertaining  to  interactions  with  the  rocket 
plumes.  In  the  design  data  base,  the  aerodynamic  interaction  with  the  plumes  was  based  on  subscale 
wind-tunnel  tests.  In  the  following  flights  in  the  OFT  program,  adjustment  of  the  aerodynamic  data 
for  consistency  with  flight  measurements  effectively  eliminated  the  lofting  phenomenon.  These  adjust- 
ments were  also  included  in  postflight  reconstructions  of  the  structural  loads.  Some  examples  are 
shown  in  figure  12.  In  the  lower  portion  of  the  figure,  the  correlation  of  an  interface  load  between 
the  Orbiter  and  the  ET  illustrates  the  generally  good  correlation  of  total  vehicle  characteristics; 
i.e.,  aerodynamics,  thrust,  and  mass  properties.  In  the  upper  portion  of  the  figure,  the  correlation 
of  a wing  load  indicator  illustrates  an  area  in  which  further  update  is  required  in  the  local  pres- 
sure distributions. 
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TEST  DATA 


ORBITER/ET 
PHD  ATTACH 
Fz(103  LB) 


FIGURE  11.-  STS-2  LIFT-OFF  MEASURED  LOADS  VERSUS  RECONSTRUCTION. 


M - MEASURED  R - RECONSTRUCTED  DATA 


FIGURE  12.-  HIGH-q  BOOST  LOADS,  MEASURED  LOADS  VERSUS  RECONSTRUCTED  LOADS. 
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CONCLUSIONS 


Because  of  its  sensitivity  to  changes  in  environmental  data,  the  Shuttle  configuration  presented 
unique  challenges  to  the  structural  loads  analyst.  Results  of  the  Orbital  Flight  Test  program  have 
generally  verified  the  design  analysis.  However,  subscale  testing  was  found  to  be  deficient  in 
predicting  full-scale  results  in  two  areas:  the  ignition  overpressure  at  lift-off  and  the 

aerodynamics/plume  interactions  at  high-q  boost.  In  these  areas,  the  results  of  the  flight  test 
program  have  been  accommodated  with  no  impact  to  the  vehicle  design.  The  challenge  of  developing 
a structural  system  which  meets  the  Shuttle  program  goal  has  been  met.  The  analytical  tools  and 
data  which  accrued  during  Shuttle  development  remain  as  significant  contributions  to  structural 


analysis  technology. 
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ABSTRACT 

The  Space  Shuttle  development  program  provided  the  opportunity  to  challenge  many  of  the 
established  practices  and  approaches  used  in  prior  manned-space-flight  programs.  The  most  signifi- 
cant accomplishments  and  resulting  precedents  which  emerged  during  the  structural  development  of  the 
Space  Shuttle  and  the  Space  Shuttle  Orbiter  are  reviewed.  Innovations  in  criteria,  design  solutions, 
and  certification  are  highlighted,  and  brief  comments  on  the  lessons  learned  are  included. 


INTRODUCTION 


As  the  final  Space  Shuttle  concepts  matured,  the  new  challenges  offered  by  the  Shuttle  main  en- 
gines, the  Orbiter  thermal  protection  system  (TPS),  and  the  Orbiter  avionics  systems  became  clearly 
visible.  The  engineering  challenges  faced  by  designers  of  the  primary  structural  system  were  created 
by  features  for  which  no  precedent  existed  and  thus  provided  the  momentum  for  creative  and  innovative 
criteria,  approaches,  and  hardware  features.  Simply  stated,  the  reusability  and  mission  flexibility 
of  the  vehicle,  the  weight  sensitivity  of  the  Orbiter  to  the  mission  requirements,  and  the  cost  con- 
sciousness of  the  project  provided  the  constant  pressure  for  innovative  design  challenges.  Although 
the  expertise  of  NASA  and  the  supporting  aerospace  team  had  been  focused  on  high-reliability  single- 
use boosters  and  spacecraft,  early  studies  identified  no  significant  technology  issues  with  struc- 
tural reusability.  As  engineering  concepts  emerged,  it  became  more  obvious  that  a considerable 
change  in  the  size  and  design  life  of  the  spacecraft  would  force  the  emergence  of  new  concepts  and 
precedents. 


DEPARTURE  FROM  FULL-SCALE  TEST  SIMULATION 

Previous  experience  had  led  to  complete  spacecraft  vibration  and  acoustic  testing  as  well  as  com- 
plete entry  vehicle  thermal  testing.  Initial  proposals  emerged  for  subjecting  forward  and  aft  sec- 
tions of  the  Orbiter  to  vehicle-level  acoustic  tests.  After  detailed  technical  and  programmatic  exam- 
ination, the  differences  with  the  past  precedents  became  clear.  Secondary  structure  and  installa- 
tions were  to  be  designed  in  accordance  with  life  requirements  for  the  Orbiter.  Generic  installation 
concepts  would  evolve  throughout  the  vehicle  and  would  require  additional  development  and  verifica- 
tion. Prevention  of  acoustic  fatigue  of  the  primary  structure  emerged  as  a serious  requirement  (fig. 
1).  This  factor  complicated  the  structural  reliability  since  extensive  coverage  of  the  Orbiter  with 
external  TPS  tiles  plus  internal  insulation  made  regular  inspection  much  more  costly  and  impractical. 
The  technical  issues  associated  with  the  complexity  of  the  environmental  simulation,  the  remaining 
unanswered  structural  and  systems  issues,  the  availability  of  the  Main  Propulsion  Test  Article  (MPTA) 
to  aid  in  vibration  and  acoustic  development,  and,  of  course,  the  significant  saving  in  test  article 
and  development  test  cost  led  to  the  challenge  of  developing  the  reusable  Orbiter  structure  without 
the  full-scale  spacecraft  vibroacoustic  test  articles.  This  challenge  was  addressed  in  the  struc- 
tural and  system  acoustic  fatigue  program  and  is  discussed  herein. 

The  large-scale  transient  thermal  response  of  the  entire  Orbiter  was  also  recognized  as  a signif- 
icant challenge  for  the  structural  discipline.  Efforts  and  approaches  such  as  those  implemented  by 
the  British  Aircraft  Corporation  for  development  of  the  Concorde  were  technically  and  programmatically 
evaluated.  The  Concorde  approach  was  to  convectively  heat  the  entire  airframe  using  a special  shroud 
and  heating  facility  while  applying  mechanical  loads  simulating  the  in-flight  load  spectra.  In  this 
program,  creep  and  fatigue  issues  for  steady-state  flight  conditions  were  addressed.  The  Orbiter  de- 
sign was  sensitive  to  the  peak  combined  transient  thermal  stress  as  it  related  to  out-of -plane  deflec- 
tion of  the  airframe  and  to  airframe  panel  stability.  Full-  and  quarter-scale  airframe  test  programs 
were  evaluated  to  address  the  challenge.  This  challenge  was  finally  addressed  through  a combined  pro- 
gram of  criteria,  structural  testing,  and  flight  testing.  The  resulting  precedents  are  discussed 
herein. 


DEPARTURE  FROM  ABORT  AND  TRAJECTORY  UNIQUE  DESIGN 

Pre-Shuttle  NASA  experience  had  been  focused  on  clearly  defined  mission  models  and  reference  tra- 
jectories. Abort  scenarios  would  emerge  as  the  most  demanding  structural  event,  and  complexity, 
cost,  and  weight  would  be  designed  into  the  spacecraft.  As  the  flexibility  of  the  Shuttle  was  exam- 
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FIGURE  1.-  PRIMARY  STRUCTURE  AREAS  SUBJECT  TO  ACOUSTICS. 


ined,  it  became  clear  that,  as  the  performance  parameters  of  payload  weight,  orbital  inclination,  and 
orbit  altitude  were  varied  over  feasible  ranges,  the  flexibility  available  through  use  of  the  engine 
throttles  led  to  a myriad  of  variations  not  easily  examined  using  direct  trajectory  simulation  for  de- 
sign. Concurrently,  the  required  system  redundancy  specified  and  the  Orbiter  weight  sensitivity  led 
to  the  design  philosophy  of  minimum  design  impact  for  abort  requirements.  Such  an  early  NASA  design 
approach  was  unprecedented.  The  direct  impact  to  the  hardware  structural  weight  was  minimized  by  de- 
sign conditions  for  loss  of  only  one  main  engine  using  rational  statistics  to  avoid  the  worst  possi- 
ble case.  Descent  operational  maneuver  and  landing  placards  were  specified  for  the  resulting  heavy- 
weight entry  and  landing.  This  approach,  of  course,  put  exceptional  pressure  on  the  abort  planners 
to  invent  concepts  which  would  "stay  within"  the  operational  capability  - an  effort  achieved  with  com- 
mendable expertise. 


SERIAL  DESIGN  EVOLUTION  OF  AIRFRAME  DESIGN  LOADS 

Results  of  early  Space  Shuttle  studies  had  shown  a clear  performance  benefit  with  increasing  dy- 
namic pressure  (q)  and  minimum  throttling.  A conscious  design  decision  was  made  to  limit  the  maximum 
dynamic  pressure  to  650  psf  nominal  and  the  maximum  longitudinal  acceleration  to  3g  axial.  The 
desired  effect  was  to  limit  the  q-sensitive  parameters  such  as  peak  differential  pressure,  buffet  in- 
tensity, aerodynamic  noise,  aerodynamic  loading,  control  authority,  and  flutter  requirements  within 
manageable  bounds.  The  constant  weight  sensitivity  and  development  of  the  emerging  flexible  capabil- 
ity of  the  Space  Shuttle  continued  and  resulted  in  changes  to  the  ascent  loading  requirements  late  in 
the  design  cycle.  Changes  to  the  detailed  structural  criteria  were  necessary  to  minimize  the  impact 
of  updated  ascent  configurations  and  the  serial  update  of  the  required  data  bases.  Although  Columbia 
and  Challenger  were  designed  to  an  early  data  base  designated  the  5.1  loads  data  base,  it  was  clear 
that  a later  certification  to  a 5.4  loads  data  base  would  have  to  be  incorporated.  The  separate  cer- 
tifications of  0V-101,  MPTA,  and  0V-102  to  different  requirements  with  different  data  bases  and 
criteria  were  a significant  challenge.  Resource  pressures  forced  a serial  approach.  The  Enterprise 
was  certified  by  analysis  and  placarded  to  80  percent  of  limit  load.  The  MPTA  was  certified  by  anal- 
ysis. The  Columbia  was  certified  by  analysis  and  testing  to  the  5.4  loads  data  base  following  par- 
tial modification  performed  in  the  field.  Further,  the  Columbia  was  restricted  to  a reduced  opera- 
tional envelope  before  final  modification.  The  Challenger  was  structurally  tested  and  returned  to 
the  fleet.  This  approach  is  unprecedented  in  NASA  experience  and  is  discussed  further  herein. 


SERIAL  DESIGN  OF  AIRFRAME  AND  TPS  INTERFACE 

The  classical  design  process  dictated  an  early  definition  of  the  structural  moldlines  and  struc- 
tural details  before  the  integration  and  final  sizing  of  the  TPS.  Early  sensitivity  of  the  TPS  to 
short  wavelength,  out-of-plane  deformations  led  to  the  selection  of  a nonbuckled  external  skin  de- 
sign. Since  the  TPS  thickness  was  not  defined  and  would  vary  depending  on  final  requirements  and 
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aerodynamic  moldlines,  a significant  challenge  was  an  adequate  but  minimum  weight  definition  of 
three-dimensional  temperature  gradients  and  stresses.  Detailed  attention  to  the  thermal  stress  addi- 
tions which  would  contribute  to  skin  buckling  was  also  required.  The  approach  to  design  definition 
and  resulting  performance  was  a worthy  challenge  and  is  discussed  further  herein. 


CRITERIA  INNOVATIONS 


DEFINITION  OF  DESIGN  LOAD  ENVELOPES 

As  the  critical  loads  analysis  studies  progressed,  it  became  obvious  that  trajectory  simulation 
of  high-q  ascent  and  descent  was  sufficiently  cumbersome  to  prevent  surveying  the  entire  flight  enve- 
lope for  hardware  design  cases.  For  ascent,  an  entirely  new  precedent,  which  was  analogous  to  the 
airframe  V-n  (velocity  versus  load  factor)  diagram  and  was  named  the  squatcheloid,  emerged.  The 
detailed  implementation  of  this  approach  is  discussed  in  reference  1.  Because  this  concept  preceded 
the  development  of  the  ascent  control  system  as  well  as  the  multimission  and  real-wind  trajectory 
simulations,  the  criterion  generated  much  debate.  There  was  genuine  concern  that  the  criterion  would 
force  the  vehicle  to  fly  through  a "tube"  of  qa/qB  versus  Mach  number  values  which,  at  that  date,  the 
ascent  control  community  had  serious  reservations  about  the  control  system  capability  to  handle. 

After  numerous  reviews,  the  weight  penalty  and  the  credibility  of  the  load  survey  associated  with  any 
other  alternative  resulted  in  the  adoption  of  the  squatcheloid;  thus,  a new  precedent  was  set  and  de- 
sign surveys  could  proceed. 

The  impact  of  this  innovation  was  readily  obvious.  The  Shuttle  vehicle  loads  analysis  was  capa- 
ble of  surveying  hundreds  of  potential  design  conditions  within  the  flight  envelope.  Load  surveys 
and  indicators  were  evaluated  even  though  the  trajectory  surveys  had  not  been  performed.  The  thrust 
structure  could  be  designed  for  compatible  engine  deflections,  consistent  with  the  control  system  and 
engine  mixing  logic  rather  than  with  a worst  case  geometric  mix.  This  criterion  also  became  an  ac- 
tive system  integration  tool.  It  allowed  the  performance , flight  control,  and  structure  disciplines 
to  work  in  parallel  rather  than  in  the  serial  manner  required  with  trajectory  simulations  and 
evaluations. 

A similar  situation  existed  with  respect  to  descent  maneuver  loading  requirements  since  only  nom 
inal  trajectory-based  data  had  emerged.  Early  ballistic  trajectories  did  not  require  any  significant 
maneuvers  and  did  not  provide  any  meaningful  "design  to"  envelopes  of  control  surface  constraints 
required  for  load  surveys.  The  initial  maximum  speed  was  defined  as  that  required  to  stall  the  actu- 
ators. The  structural  criterion  was  baselined  using  Mach-number-dependent  V-n  diagrams  illustrated 
in  figure  2.  The  maximum  speed,  equivalent  to  375  psf,  was  derived  from  upsetting  the  nominal  trajec 
tory  and  recovering  and  was  tempered  with  understanding  of  the  entry  control  system  limits.  Modifica 
tions  to  aircraft  maneuver  requirements  such  as  limiting  the  maximum  yawing  load  factor  to  3/4g  were 
also  derived.  Envelopes  for  the  control  surface  were  generated  so  that  a complete  loading  survey 
could  be  performed.  Since  no  deterministic  flight  conditions  to  justify  the  myriad  of  descent  cases 
existed,  this  criterion  also  generated  serious  review.  The  criterion  was  found  to  be  the  logical  al- 
ternative and  set  a precedent  of  deviating  from  deterministic  ballistic  load  definition. 


DEFINITION  OF  COMBINED  STRESS  CRITERIA 

Once  the  trade-off  studies  showing  the  relative  insensitivity  of  the  unit  weight  of  structural 
effective  thickness  plus  TPS  unit  weight  to  maintain  a temperature  of  350°  F (fig.  3)  were  performed, 
the  decision  to  preclude  buckled  external  skin  became  the  baseline  approach.  Using  techniques  such 
as  those  documented  in  reference  2,  the  frame  and  rib  spacings  were  set  for  minimum  structural 
weight.  As  the  design  concepts  evolved,  it  became  apparent  that  the  local  skin  deflections  amplified 
by  the  beam  column  effect  over  relatively  short  wavelengths  were  important  to  the  induced  through- 
the-thickness  stresses  in  the  TPS.  A consistent  approach  to  and  method  of  combining  the  stresses 
were  needed  to  assure  adequate  and  uniform  specification  of  skin  peak  stress.  The  criterion  of  fig- 
ure 4 was  specified  after  some  debate  and  trade-off  study.  This  level  of  specified  combined  stress 
criterion  was  unprecedented  for  design  of  manned  spacecraft.  As  weight-saving  pressures  mounted,  the 
assurance  provided  by  the  criterion  contributed  to  further  sophistication  in  the  skin  deformations. 
The  post-heating  criterion  on  skin  buckling  was  relaxed  from  no  buckling  at  115  percent  of  limit 
load  to  100  percent  limit  load. 


EMPHASIS  ON  FRACTURE,  LIFE,  AND  ALLOWABLE  DEFORMATIONS 

Studies  were  performed  to  assess  the  approach  to  implementing  fracture  control  on  the  primary 
airframe.  Fracture  control  plans  were  generated  by  the  contractors  and  approved.  The  importance  of 
the  fracture  requirement,  the  life  requirement  of  the  structure,  and  the  ratio  of  yield  to  ultimate 
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stress  of  modern  materials  led  to  the  unprecedented  approach  of  not  specifying  a yield  factor.  It 
was  shown  that  a yield  factor  could  be  misinterpreted  during  preliminary  design  and  that  the  pre- 
ferred approach  was  to  focus  on  the  deformations  and  on  fracture  and  life  requirements. 


DEFINITION  OF  FEASIBLE  CREW  CABIN  WEIGHT 

As  the  crew  cabin  design  evolved,  it  was  noted  that  the  specific  design  missions  compared  to  the 
available  volume  resulted  in  considerable  opportunity  for  weight  growth.  Apollo  command  module  volu- 
metric stowage  densities  were  reviewed.  The  result  was  that  the  structural  design  of  the  crew  cabin 
was  performed  using  a value  of  30  000  pounds  even  though  specific  mission  requirements  could  not  de- 
fine weights  above  27  891  pounds.  This  provision  proved  to  be  well  worth  the  minor  scar  weight  of  ap- 
proximately 57  pounds  and  allowed  very  flexible  mission  planning  with  non-weight-limited  stowage  vol- 
umes used  for  payload  and  mission  integration. 


DEFINITION  OF  DESIGN  BUDGET  FOR  THERMAL  STRESS 

Results  of  early  studies  had  not  revealed  the  complexity  of  defining  design-case  thermal 
stresses.  With  the  extreme  pressure  of  "designing  out"  Orbiter  structural  weight,  redesign  to  desen- 
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7075-T6  7075-T6  2024-T81  7075-T6  HM21 A-T87075-T6  AL/Ti  Be/Ti  6AL-4V 

AL  STRUCT.;  AL  AL  AL  Mg  AL  STRUCT.;  STRUCT.;  Ti  STRUCT.; 

SLA-561  STRUCT.;  STRUCT.;  STRUCT.;  STRUCT.;  STRUCT.; LI-1 500/Ti  LI-1500  LI-1500 

ABLATOR  LI-1500  LI-1500  LI-1500/  LI-1500  METALLIC  SUBPANEL 

Be  SUBPANEL  TPS 

FIGURE  3.-  ORB  ITER  STRUCTURE/TPS  FIRST  UNIT  COST  COMPARISON. 

3. 2. 2. 2. 6 ULTIMATE  COMBINED  LOADS.  THE  MECHANICAL 
EXTERNAL,  THERMALLY  INDUCED,  AND  INTERNAL  PRESSURE 
LOADS  SHOULD  BE  COMBINED  IN  A RATIONAL  MANNER 
ACCORDING  TO  THE  EQUATION  GIVEN  BELOW  TO  DETERMINE 
THE  DESIGN  LOADS.  ANY  OTHER  LOADS  INDUCED  IN  THE 
STRUCTURE,  E.G.,  DURING  MANUFACTURING,  SHALL  BE 
COMBINED  IN  A RATIONAL  MANNER.  IN  NO  CASE  SHALL  THE 
RATIO  OF  THE  ALLOWABLE  LOAD  TO  THE  COMBINED  LIMIT 
LOADS  BE  LESS  THAN  1.40 


K-|L  EXTERNAL  + K-|L  THERMAL  + K2L  PRESSURE,  > 1.40  2 L 
K1  =1.4  WHEN  THE  TERM  IS  ADDITIVE  TO  THE  ALGEBRAIC 
SUM,  X L 

K2  = 1.5  FOR  TANKAGE  WHEN  THE  TERM  IS  ADDITIVE  TO  THE 
ALGEBRAIC  SUM,  X L 

Ki,  K2  = 1.0  WHEN  THE  TERM  IS  SUBTRACTIVE  TO  THE  ALGEBRAIC 
SUM,  X L 


FIGURE  4.-  COMBINED  LOADS  CRITERIA. 
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sitize  the  minimum  weight  concepts  from  thermal  stresses  was  not  practical.  Also  considered  was  the 
concept  of  a tolerance  on  the  thermal  gradients.  Although  seemingly  logical,  a three-dimensional  fi- 
nite-element model  was  not  suitable  for  a consistent  combination  approach.  An  automated  worst  case 
would  have  inferred  different  temperatures  at  the  same  node  point.  This  conflict  implied  inconsis- 
tent added  weight,  and  the  concept  was  rejected.  Results  of  studies  performed  showed  the  sensitivity 
of  the  initial  conditions  achieved  on  orbit.  These  data  showed  that  approximately  30  percent  of  the 
total  stress  could  be  attributed  to  thst  "locked  in"  at  entry  interface. 

Tail  Sun,  top  Sun,  side  Sun,  and  nose  Sun  attitudes  and  initial  conditions  from  a once-around 
mission  were  chosen  as  design  initial  conditions.  Theoretical  thicknesses  of  TPS  tiles  were  speci- 
fied for  approximately  100  three-dimensional  models.  The  gradients  were  assessed  and  several  time 
points  were  selected  for  detailed  analysis.  These  data  were  then  hand-faired  and  extrapolated  to  the 
entire  finite-element  grid.  This  procedure  involved  judging  the  temperatures  to  about  100  times  the 
resolution  of  the  thermal  analysis.  This  experience  demonstrated  the  technology  weakness  of  determin- 
ing the  design-case  transient  thermal  stress  for  large  three-demensional  structures.  The  design  was 
frozen  to  this  budget  of  thermal  stress.  It  remains  for  operational  planners  to  ensure  that  the  oper- 
ational envelope  stays  within  the  budget. 


MATERIAL  BASELINE  OF  THE  PRIMARY  STRUCTURE 

In  selecting  the  materials  for  the  "airframe"  of  the  combined  airplane/spacecraft  Orbiter,  the 
conventional  trade-off  studies,  considering  the  costs  to  produce  the  first  unit  and  the  weight,  had 
to  accurately  reflect  the  compatibility  requirements  imposed  on  the  structure  by  the  external  TPS. 

The  very  low  strength,  brittle  TPS  tiles,  which  were  to  be  bonded  to  the  skin  of  the  Orbiter,  re- 
quired that  the  skin  not  buckle  when  exposed  to  115  percent  of  maximum  expected  loads  (limit  load) 
during  ascent  and  100  percent  of  the  maximum  expected  load  during  atmospheric  entry.  From  a weight 
standpoint,  this  skin-buckling  requirement  made  aluminum  and  titanium  equivalent  since  the  ratio  of 
the  compression  modulus  to  density  is  approximately  the  same  for  both  materials  (Ec/P  = 10  x 10? 
inches).  The  structure  of  the  Orbiter,  sized  by  flight  loads  where  the  material  could  be  worked  to 
high  stresses,  favored  the  high-strength  materials  such  as  titanium.  The  third  general  category 
considered  in  the  structural  material  selection  was  the  heat  capacitance  and  the  strength  at  elevated 
temperatures.  When  considering  the  requirements  of  buckling  for  TPS  compatibility,  strength,  heat 
capacitance,  conductance,  and  a few  other  factors,  the  combined  weight  of  the  structure  and  the  TPS 
was  approximately  15  percent  less  for  titanium  than  for  aluminum  as  the  primary  structure;  however, 
the  cost  for  the  titanium  structure  was  approximately  300  percent  greater  than  that  for  aluminum.  The 
much  higher  production  cost  and  the  higher  production  development  risk  for  titanium  and  the  system 
performance  studies  resulted  in  selection  of  aluminum  for  the  basic  primary  structure. 

There  were  two  major  areas  of  the  primary  structure  for  which  aluminum  was  not  selected  - the 

payload  bay  doors  and  the  main  engine  thrust  structure.  The  payload  bay  doors  were  designed  for  maxi- 

mum reliability  in  opening  and  closing  in  space.  To  help  achieve  this  reliability,  the  doors  were  de- 
signed so  they  could  be  "zipped"  up  during  closure.  This  zipping  capability  dictated  that  the  doors 
be  flexible  and  have  large  clearances  between  door  segments  and  surrounding  structure.  To  help  meet 
these  requirements,  the  Orbiter  primary  structure  was  designed  so  that  the  doors  were  not  affected  by 
fuselage  bending  (only  by  pressure  and  torsion  loads).  The  large,  flexible  payload  bay  doors,  which 
had  very  few  TPS  tiles,  were  then  optimized  for  weight,  thermal  distortion,  and  cost.  Graphite  epoxy 
was  selected  as  the  material. 

The  thrust  structure  reacts  1.5  million  pounds  of  Space  Shuttle  Main  Engine  thrust  load  and  dis- 
tributes the  vertical  stabilizer  loads  and  external  tank  aft  attachment  loads  into  the  fuselage.  The 

material  selected  for  this  highly  loaded  structure  was  titanium.  For  long  truss  members  that  were 
compression/buckling  critical,  the  weight  was  reduced  by  overlaying  longitudinal  strips  of  boron 
epoxy.  The  thermal  expansion  compatibility  between  the  titanium  and  the  boron  epoxy  permitted  this 
composite  system.  The  system  reliability  was  increased  by  sizing  the  titanium  structure  so  that 
limit  load  could  accommodated  on  any  structural  member  even  if  a segment  of  the  boron  epoxy  became 
debonded. 

The  general  arrangement  of  the  Orbiter  primary  structure  and  the  materials  used  is  shown  in 
figure  5. 
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AFT  FUSELAGE 

• ALUMINUM  SKIN/STR  SHELL 

• TITANIUM/BORAN  THRUST 
STRUCTURE 

• GRAPHITE/EPOXY  APS 
SKIN  PANELS 


VERTICAL  TAIL 


ALUMINUM  MACHINED 
SKINS 

ALUMINUM  HONEYCOMB 
RUDDER  COVERS 


BODY  FLAP 
• ALUMINUM 
HONEYCOMB 
COVERS 


FORWARD  FUSELAGE 
& 

CREW  CABIN 
• ALUMINUM 
SKIN/STR 


• CONVENTIONAL  ALUMINUM  STRUCTURE 

• MAXIMUM  TEMPERATURE  350°  F 

• PROTECTED  BY  REUSABLE  SURFACE  INSULATION 


PAYLOAD  BAY  DOORS 

• GRAPHITE/EPOXY 
HONEYCOMB  PANELS 

• GRAPHITE/EPOXY 
FRAME 


‘—WING 

• ALUMINUM  SKIN/STR  & HONEYCOMB  COVERS 

• ALUMINUM  WEB  & TRUSS  SPARS 

• ALUMINUM  HONEYCOMB  ELEVON  COVERS 


FIGURE  5.-  ORB  ITER  STRUCTURE. 
DESIGN  INNOVATIONS 


ORBITER  WINDOW  SYSTEM 

The  Orbiter  window  system  shown  in  figure  6 represents  a significant  and  unheralded  achievement 
in  glass  structural  technology.  The  Corning  Glass  Company  agreed  to  produce  the  windows  as  a na- 
tional service.  Fracture  mechanics  criteria  were  used  to  design  the  untempered  1200  pounds  of  fused 
silica  glazings.  Sustained  load  flaw-growth  requirements  set  the  proof  test  requirement  at  8600  psi 
to  screen  a flaw  of  0.0018  inch.  Initially,  serious  technology  reservations  were  expressed  because 
of  the  "mass  effect"  of  the  large  boules  weighing  approximately  2000  pounds  each.  Development  of  the 
processes  and  coating  verification  required  2 years  of  challenging  engineering.  Because  of  changes 
in  aerodynamic  data  and  lessons  learned  from  the  flight  data,  critical  inspection  and  polishing  of  the 
operational  windows  are  necessary  to  asssure  the  life  of  the  window. 


MAJOR  STRUCTURAL  CONCEPT  STUDIES 

Several  major  studies  were  performed  to  define  the  minimum-weight  structural  concepts.  These 
studies  had  been  identified  as  a result  of  the  phase  B options  that  had  been  proposed.  Trade-off 
studies  were  performed  by  the  contractor  and  by  in-house  NASA  engineering  groups.  For  example,  it 
was  shown  that  a space  frame  concept  for  the  thrust  structure  would  save  approximately  1730  pounds  as 
compared  with  a competing  plate  girder  concept.  Similarly,  it  was  shown  that  integration  of  the  aft 
carrythrough  spar  with  the  1307  bulkhead  would  save  approximately  450  pounds  compared  to  a floating 
carrythrough  and  would  require  a corrugated  bulkhead  web  to  limit  the  stress  concentrations.  A 
single-point  drag  attachment  between  the  Orbiter  and  the  external  tank  was  studied  since  it  achieved 
a statically  determinate  interface.  It  was  found  to  be  heavier  and  more  difficult  to  integrate  with 
the  natural  load  paths  from  the  thrust  structure.  Results  of  other  studies  confirmed  the  weight  ef- 
fectiveness of  the  separate  crew  module  as  compared  to  an  integrated  fuselage  and  crew  module.  The 
requirement  for  the  payload  bay  doors  to  react  body  torsion  while  precluding  vehicle  bending  was 
confirmed.  Weight  and  cost  studies  led  to  the  selection  of  the  composite  material  systems  used  in 
the  payload  bay  doors,  the  Orbital  Maneuvering  System  (0MS)  pod  external  shell,  frame  and  rib  tubes, 
and  the  thrust  structure.  These  concept  selections  resulted  from  penetrating  engineering  trade-off 
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studies.  The  weight  "scraping”  which  followed  was  the  next  significant  milestone  as  the  loads  ma- 
tured. Significant  weight  reduction  was  achieved  on  Orbiter  vehicles  0V-103  and  0V-104.  Attention 
to  detail,  with  the  successful  development  period  confirming  the  stress  distributions,  led  to  struc- 
tural weight  reduction  of  approximately  1000  pounds. 


ORBITER  VENTING  SYSTEM 

Design  of  the  Orbiter  venting  system  involved  challenges  not  previously  encountered.  Previous 
spacecraft  experience  dictated  a design  which  would  have  connected  the  entire  volume  and  vented  it 
through  base  vent  areas.  Because  of  the  requirements  of  contamination  and  cleanliness  of  the  payload 
bay  and  the  potential  hazards  of  hydrogen  concentrations,  a multicompartment  scheme  of  self-vented, 
passively  vented,  and  controlled  venting  compartments  evolved.  This  arrangement  required  the  vent 
areas  to  be  distributed  around  the  vehicle  and  required  that  they  be  placed  and  sized  so  as  to  accom- 
modate significant  variations  in  pressure  coefficient  at  the  vent.  The  definition  of  design  differen- 
tial pressures  across  the  internal  bulkheads  required  extensive  analysis  to  identify  the  critical  com- 
bination of  venting  parameters.  The  resulting  design  and  performance  are  discussed  in  reference  3. 
Overall,  the  system  performed  as  designed,  is  tolerant  of  failures  and  variations,  and  has  adapted 
well  to  changes  in  design  data  and  initial  requirements.  Although  it  has  been  largely  unnoticed,  it 
represents  an  outstanding  example  of  a thorough,  innovative  design  achievement. 
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ACOUSTIC  FATIGUE 


Fatigue  of  the  Orbiter  structure  was  considered  by  many  engineers  and  managers  to  be  inconse- 
quential since  the  design  life  was  for  100  missions  and  only  a few  hours  of  flight  in  the  atmosphere. 
By  comparison  to  the  classical  airplane  ground-air-ground  leading  cycles  for  a 20  000-hour  airframe, 
the  Orbiter  did  have  reduced  requirements;  but,  when  considering  the  high  acoustic  levels  (fig.  7), 
high  cycle,  low-stress  fatigue  could  not  be  ignored. 

The  challenge  was  in  certifying  this  large,  complex,  multimaterial,  multiconfiguration,  multi- 
manufactured  source  structure  for  multicombinations  of  loads  for  the  high  acoustic  levels.  The 
obvious  solution  was  to  certify  by  testing  as  is  done  for  airplanes  - apply  a spectrum  of  flight 
loads  to  a dedicated  test  airframe  for  as  many  as  four  times  the  number  of  expected  load  cycles. 

The  Concorde  airplane,  which  was  designed  for  elevated  temperatures  (200°  C),  was  fatigue-tested 
in  the  classical  manner  while  simultaneously  being  convectively  heated.  Such  a test  program  for 
the  Orbiter  would  have  required  a dedicated  structural  test  article  (costing  approximately  $100 
million),  a nonexistent  acoustic  facility,  and  a method  of  imposing  rapidly  changing  temperatures 
on  the  structure.  The  cost,  schedule,  and  technical  capability  were  out  of  reach. 

The  acoustic  fatigue  certification  program  established  was  truly  innovative.  The  concept  was  to 
test  representative  structure  of  various  forms,  materials,  and  construction  in  a representative  acous- 
tic environment  until  the  test  article  failed.  (The  regions  to  be  tested  are  shown  in  fig.  8.)  This 
procedure  would  result  in  establishing  an  acoustic  fatigue  damage  allowable  for  each  type  of  material 
and  construction.  The  allowable  damage  would  then  be  reduced  analytically  to  account  for  the  damage 
induced  by  the  flight  loads  and  elevated  temperature.  The  test  articles  were  sized  so  that  only  one- 
third  of  the  specimen  was  the  test  region  - the  remaining  two-thirds  of  the  specimen  was  compromised 
because  of  the  boundary  conditions.  Several  of  the  test  articles  are  shown  in  figures  9 to  11. 

This  approach  was  modified  for  some  test  articles  like  the  payload  bay  doors,  which  have  great 
fatigue  durability  because  of  the  graphite  epoxy  construction.  The  compromise  consisted  of  not 
testing  to  failure  but  instead  of  analytically  modeling  the  structure  and  correlating  with  strain 
measurements  from  the  test.  The  test  articles  were  then  used  as  flight  hardware. 

Additional  acoustic  fatigue  certification  objectives  relative  to  secondary  structure,  system 
installations,  and  TPS  were  also  accomplished  on  many  of  the  test  articles.  This  additional  hardware 
was  "piggybacked"  on  the  test  articles. 


STRUCTURAL  TEST  APPROACH 

Detailed  planning  of  the  structural  test  conditions  was  well  underway  for  a classical  static 
test  program  followed  by  fatigue  investigations  when  a new  opportunity  emerged.  The  Orbiter  struc- 
ture had  evolved  under  such  weight-saving  pressure  that  virtually  all  the  primary  structure  had  a sig- 
nificant thermal  stress  component.  Attempts  to  factor  mechanical  loading  into  equivalent  thermal 
loadings  resulted  in  inconsistent  stress  distributions  which  were  not  meaningful  simulations.  Thus, 
it  became  clear  that  the  classical  demonstration  of  design  ultimate  strength  was  not  feasible  without 
a thermal  simulation.  Such  a simulation  was  not  practical  and  probably  not  possible  for  the  tran- 
sient cases  of  interest.  The  objective  of  the  test  then  had  to  emphasize  the  correlation  of  the 
stress  analysis  with  the  measured  strain  data.  It  also  became  evident  that  a test  to  ultimate  load 
(1.4  times  limit)  would  not  achieve  design  ultimate  stresses  but  would  probably  result  in  deforma- 
tions and  strains  to  render  the  airframe  unusable  for  flight.  At  the  same  time,  it  became  clear 
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FIGURE  8.-  ORBITER  ACOUSTIC  FATIGUE  TEST  ARTICLES. 


FIGURE  9.-  NOSE  CAP  TEST  ARTICLE.  FIGURE  10.-  VERTICAL  STABILIZER  TEST  ARTICLE. 
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FIGURE  11.-  QMS  POD  TEST  ARTICLE. 


that  the  structural  test  article  (0V-099)  had  to  be  proved  acceptable  with  the  5.4  loads  data  base 
even  though  it  had  been  designed  for  the  5.1  data  base.  From  this  situation  emerged  a precedent- 
setting proposal:  (1)  test  to  1.2  times  the  5.4  loads,  (2)  require  detailed  stress  analysis  of 
each  test  condition,  (3)  include  unit  load  test  evaluations  where  required,  (4)  perform  a combined 
thermal  and  mechanical  test  of  the  forward  fuselage,  (5)  instrument  sufficiently  to  compare  with  anal- 
ysis and  identify  peak  critical  stresses,  (6)  perform  additional  component  test  investigations  for  ul- 
timate strength  and  fatigue  of  identified  critical  interface  hardware,  (7)  perform  and  document  a 
critical  post-test  inspection,  and  finally,  (8)  refurbish  the  airframe  structure  for  use  as  a flight 
vehicle.  Daring  as  this  proposal  initially  sounded,  the  technical  detail  and  innovative  imagination 
was  sustained  through  complete  management  review  as  well  as  special  technical  review  teams. 

The  test  was  a remarkable  accomplishment.  Thirty-nine  test  conditions  simulating  32  critical  de- 
sign conditions  were  used.  The  engine  thrust  loads  required  innovative  design  concepts  to  accurately 
position  the  engine  thrust  vector.  A typical  test  involved  control  of  256  jack  loads  which  were  dis- 
tributed over  836  load  application  points.  Because  of  lack  of  agreement  with  analysis,  a complete  in- 
fluence test  program  was  performed  on  the  thrust  structure;  this  program  resulted  in  a high-fidelity 
empirical  math  model.  Partial  influence  coefficient  tests  were  performed  on  the  payload  reactions. 

The  thermal  test  was  accomplished  on  the  forward  fuselage  by  heating  the  external  skin  with  external 
resistive  blankets  controlled  in  six  zones.  Cooling  was  provided  by  gaseous  purge  of  the  internal 
frame  caps.  When  the  test  temperatures  and  gradients  had  been  achieved,  mechanical  loading  was  ap- 
plied to  simulate  the  nose  gear  impact  inertial  loads. 

The  results  of  the  testing  were  quite  impressive  and  may  be  summarized  as  follows.  The  stress 
distributions  in  the  critical  test  regions  compared  within  10  percent  of  the  analysis  with  few  ex- 
ceptions. Exceptions  were  noted  in  the  external  tank  forward  and  aft  fittings  and  support  structure, 
in  the  distribution  of  reaction  between  the  front  and  aft  spars  of  the  vertical  stabilizer,  and  in 
the  y-load  distribution  of  the  main  gear  reaction.  Supplementary  instrumentation  and  component  test 
articles  were  defined  to  fully  instrument  and  certify  these  regions.  The  thermal  test  measured 
stresses  compared  well  (10  percent)  with  those  measured  on  the  frames  and  internal  structure.  The 
skin  stresses  in  the  circumferential  directions  were  considerably  less  (30  percent)  than  predicted 
analytically  and  in  good  agreement  longitudinally.  Hardware  modifications  resulting  from  the  test 
data  were  identified.  The  forward  reaction  control  system  tank  support  structure,  which  failed  in 
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test  because  of  inadequate  lateral  stiffness,  was  redesigned,  retested,  and  implemented.  The  empir- 
ical load  distribution  between  front  and  aft  spars  of  the  vertical  stabilizer  resulted  in  drag  angle 
modifications,  which  were  implemented  after  component  retest.  The  lateral  load  sharing  of  the  main 
gear  reaction  was  used  to  define  the  shimming  and  rigging  specifications.  The  deflections  measured 
around  the  nose  landing  gear  door  were  used  to  define  the  rigging  requirements. 

The  proof  test  concept  used  on  the  Challenger  vehicle  continues  to  achieve  significant  cost  sav- 
ings as  it  has  been  applied  to  several  Space  Transportation  System  (STS)  payloads.  This  concept 
is  a recognized  verification  concept  for  payloads  as  specified  in  JSC-14046.  It  is  emphasized 
that  use  of  this  approach  requires  detailed  engineering  with  attention  to  the  structural  details, 
sufficient  instrumentation,  and  rigorous  post-test  inspection. 


LESSONS  LEARNED 


THERMAL  STRESSES 

Mathematical  surveys  of  peak  transient  thermal  stresses  were  not  technically  feasible  using  the 
operational  tools  of  the  early  1970 ' s . Technology  and  computational  capacity  are  now  available  to 
perform  integrated  thermal /thermal  stress  surveys  analogous  to  those  used  to  identify  the  critical 
aerodynamic  loading  conditions.  These  analysis  tools  should  be  exercised  and  tested  against  flight 
data.  Such  studies  would  determine  the  criteria,  extent,  and  accuracy  of  the  methods  before  their 
use  on  the  next  major  program. 


GRAPHITE  EPOXY  MOISTURE 

Graphite  epoxy  structure  will  absorb  moisture  by  diffusion  and  will  degrade  in  strength  prop- 
erties at  temperatures  above  250°  F.  It  should  also  be  noted  that  the  honeycomb  configurations 
can  absorb  enough  moisture  to  be  susceptible  to  failure  by  vaporization  of  the  moisture  and  rupture 
of  the  honeycomb  panel.  Flight  data  appear  to  indicate  that  the  thermal  conductivity  of  such  panels 
is  complex.  During  the  STS-1  mission,  vaporization  at  a temperature  exceeding  250°  F caused  the 
failure  of  a portion  of  the  QMS  fairing. 


WINDOW  STRUCTURE 

Window  design  stress  and  sustained  load  flaw-growth  parameters  are  sensitive  to  detailed  knowl- 
edge of  the  loading  environment,  and  the  windows  are  susceptible  to  damage  in  flight  as  well  as  on 
the  ground.  Future  technology  thrusts  are  warranted  to  develop  high-temperature  glazings  which  are 
effectively  tempered,  perhaps  by  preloading  concepts  rather  than  conventional  techniques.  Annealed 
glazings  should  be  used  with  comfortable  conservative  margins. 


STRUCTURAL  INSPECTION 

Detailed  routine  structural  inspection  of  large  spacecraft  will  continue  to  be  laborious  and 
costly  because  of  the  required  insulation  systems.  Technology  advances  are  required  to  identify 
structural  damage  without  requiring  removal  of  the  thermal  systems.  An  innovative  technique  could  be 
effectively  tested  and  implemented  during  the  STS  operational  era. 
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ABSTRACT 


The  External  Tank  (ET)  has  been  actively  involved  in  performance  improvements  since  the  inception 
of  the  program,  primarily  by  weight  savings.  Weight  savings  were  realized  on  the  first  block  of  flight 
articles  [Standard  Weight  Tank  (SWT)].  With  a need  for  further  performance  improvements,  the  ET  Program 
Office  was  requested  to  develop  a program  to  reduce  tank  weight  an  additional  6000  lb  and  schedule 
delivery  of  the  first  lightweight  ET  (LWT)  for  June  1982. 

The  weight  savings  program  was  accomplished  by  (1)  a unique  approach  to  use  of  factors  of  safety, 
(2)  design  optimization,  and  (3)  redesign  of  structures  with  large  margins  of  safety  which  resulted  in 
an  actual  weight  savings  of  7294  lb.  Additional  studies  have  identified  further  weight  savings  which 
will  be  implemented  at  appropriate  times  in  production  flow.  Examples  are  an  improved  TPS  system  for 
the  LH2  tank  aft  dome  and  reduction  of  slosh  baffles  in  the  L02  tank  based  on  flight  data.  All  per- 
formance improvements  were  compared  and  selected  based  on  non-recurring  and  recurring  cost  and  technical 
risk. 


INTRODUCTION 

The  primary  method  of  ET  participation  in  Shuttle  performance  improvement  is  weight  savings. 

Weight  savings  were  realized  in  the  first  block  of  flight  articles  (ET-1  through  ET-6)  as  all  had  actual 
weights  less  than  specification  (Fig.  1).  This  was  attributed  to  having  to  establish  the  specif ication 
weight  using  the  high  side  of  tolerance  bands  for  metal  and  thermal  protection  system  material  thick- 
nesses, whereas,  the  actual  thicknesses  were  less  than  nominal. 

Because  the  ET  is  the  structural  backbone  of  the  Space  Shuttle,  load  paths  are  complex,  making 
weight  reduction  a difficult  task  (Fig.  2).  With  the  challenge  to  reduce  the  weight  of  the  basic  design 
by  6000  lb  to  improve  Shuttle  performance  and  since  the  ET  is  the  only  expendable  element  of  the  Shuttle 
economics  of  saving  weight  was  extremely  important.  The  weight  savings  were  achieved  for  only  $75/lb/ 
flight  increase  in  1978  dollars  (Fig.  3). 

An  initial  list  of  30  weight-saving  candidates  was  identified  with  a potential  saving  of  7500  lb, 
providing  a 20%  contingency  to  assure  the  required  6000  lb.  A screening  process  was  established  based 
on  recurring  and  non-recurring  costs  as  discriminators  using  a 1978  dollar  base.  The  recurring  cost 
screen  was  selected  at  $75/lb  for  welded  aluminum  fabrication  and  the  non-recurring  cost  was  $15, 000/lb 
based  on  removing  the  same  weight  from  the  Orbiter.  Since  it  was  difficult  to  mix  the  Standard  Weight 
Tank  (SWT)  and  the  Lightweight  Tank  (LWT)  across  the  same  tools,  a single  production  line  concept  was 
used  to  minimize  total  costs. 


WEIGHT  SAVINGS  PROGRAM 


The  weight-savings  program  was  focused  primarily  on  structural  components  and  was  accomplished  by 
using  the  SWT  and  optimizing  that  design  for  LWT  loads  and  environments  to  arrive  at  the  LWT  design. 
Additionally,  all  excessive  margins  of  safety  were  reduced  and  a unique  approach  to  factors  of  safety 
was  applied.  This  approach  was  tailored  to  repeatability  and  predictability  of  loads.  The  standard 
factor  of  safety  (F.S.)  of  1.40  was  applied  to  all  aerodynamic  and  dynamic  loads;  whereas,  a F.S.  of 
1.25  was  applied  to  all  well-defined  loads,  i.e. , thrust  loads,  internal  pressure,  inertia  loads  (Fig. 
4).  The  resulting  combined  equation, 

„ _ _ (1.25  S/S  + 1.40  DYN.) 

S/S  + DYN 

yields  a factor  of  safety  between  1.25  and  1.40. 

- S/S  = Steady  State  Loads  (well-defined) 

- DYN  = Aerodynamic  and  Dynamic  Loads 
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As  the  result  of  applying  these  factors  to  redesign  and  optimization,  a total  weight  saving  from 
the  SWT  to  LWT  of  7294  lb  resulted. 


DESIGN  OPTIMIZATION 

Most  of  the  significant  design  optimization  candidates  not  only  saved  weight  (2748  lb),  but  also 
resulted  in  lower  recurring  cost.  The  major  weight  saving  items  are  the  antigeyser  line  deletion,  cross- 
beam depth  increase,  LH2  tank  stringer  removal,  Fire-Retardant  Latex  (FRL)  coating  deletion,  and  changing 

interface  hardware  fitting  material  to  Ti-641-4V  (Fig.  5). 

Antigeyser  line  deletion  (Fig.  6),  replaced  by  helium  (He)  injection  in  the  main  feedline  to  pre- 
vent geysers,  took  four  years  to  develop  through  extensive  flow  testing  in  a lox  feedline  simulator  and 
system  testing  on  the  Main  Propulsion  Test  Article  at  NSTL.  Main  feedline  injection  is  possible  because 
helium  rising  in  the  feedline  provides  transpiration  cooling  to  keep  the  liquid  below  saturation  tem- 
perature, thus  precluding  formation  of  vapor  which  causes  geysering.  The  change  eliminated  expensive 
propulsion  hardware  and  a TPS  ablator  strip  along  most  of  the  length  of  the  LH2  tank  with  more  efficient 

packaging  of  the  propulsion  lines  (GH2  pressurant  line  moved  to  former  location  of  the  antigeyser  line) . 
The  total  weight  savings  of  this  change  was  666  lb. 

The  ET/Orbiter  aft  crossbeam  height  was  deepened  and  chord  thickness  was  reduced  providing 
increased  structural  stiffness  with  a resulting  weight  saving  of  91  lb  (Fig.  7).  The  ET/Orbiter  aft 
crossbeam  is  limited  by  its  proximity  to  the  Orbiter.  A flow  restrictor  attached  to  the  top  of  the  aft 
crossbeam  was  eliminated  to  allow  increased  height.  This  structure  is  an  attractive  candidate  for 
composite  construction. 

A net  savings  of  235  lb  was  achieved  by  deletion  of  some  of  the  stringer  and  Z-frames  (Fig.  8)  in 
the  LH2  tank,  optimization  of  design  of  the  Station  2058  frame  and  several  intermediate  frames,  and 

operational  optimization  for  loading  the  LH^  tank.  Detailed  finite  element  structural  analyses  in 

conjunction  with  cryogenic  structural  tests  of  the  SWT  LH2  tank  at  MSFC  showed  that  many  of  the  integral 

stringers  on  the  -Z  axis  (side  away  from  Orbiter)  and  the  intermediate  Z-frames  in  five  locations  could 
be  eliminated.  Originally,  the  stringers  and  Z-frames  were  designed  in  to  make  as  many  of  the  LH2  tank 

parts  common  to  each  other  as  possible  for  low  cost.  The  2058  frame  was  optimized  by  reducing  backup 
fittings  and  reconfiguring  stiffener  design.  Operational  optimization  was  required  to  allow  the  LH2 

tank  to  be  loaded  without  preload  to  assure  no  bulkhead  buckling.  Additional  material  was  added  to  the 
aft  LH2  bulkhead  to  assure  no  buckling. 

Since  operational  ETfs  will  not  be  exposed  for  long  periods  on  the  pad,  TPS  top  coat  (Fire-Retardant 
Latex)  could  be  eliminated  over  most  of  the  acreage.  The  rind  of  the  as-sprayed  CPR-488  Spray-On  Foam 
Insulation  (SOFI)  provides  adequate  protection  from  the  elements  for  short  periods  of  time  (11  weeks). 
Areas  where  rind  has  been  removed  require  painting  with  matching  color  top  coat.  Over  580  lb  were  saved 
by  elimination  of  the  top  coat. 

Major  interface  fittings  were  changed  to  more  efficient  and  available  materials.  All  titani  mi 
alloy  fittings  at  the  SRB/ET  interfaces  were  changed  from  Ti-5Al-2.5  Sn  to  more  widely  used  T1-6A1-4V 
because  of  higher  strength  (Fig.  9).  Most  of  the  ET/Orbiter  interface  hardware  (thrust  struts,  vertical 
struts  and  diagonal  struts)  had  material  change  from  7075-T73  to  7050-T73  to  take  advantage  of  the 
10  percent  strength  increase.  The  total  weight  savings  from  all  these  changes  was  379  lb. 

Other  weight  savings  attributed  to  design  optimization  include  miscellaneous  hardware  in  the 
Intertank,  using  an  integrated  receiver /decoder  in  the  range  safety  system,  miscellaneous  electrical 
wiring  changes  and  deletions  of  development  flight  instrumentation  and  Thermal  Protection  System  (TPS) 
thickness  optimization  on  the  L02  and  LH2  tanks.  These  savings  totaled  797  lb. 

MARGINS  OF  SAFETY  REDUCTIONS 

Structural  margins-of-saf ety  were  reduced  by  changing  design  criteria  (LH2  proof  test)  and  tailor- 
ing the  structure  to  specific  internal  loads  (Fig.  10).  Commonality  was  reduced  resulting  in  most 
margin  reduction  items  increasing  recurring  costs.  Those  selected  met  the  $75/lb  criteria.  Total 
weight  saved  by  margin  reduction  amounted  to  3244  lb. 

The  LH2  tank  proof  test  was  originally  based  on  a relief  pressure  of  37  psig.  This  was  changed 
to  a maximum  operating  pressure  basis  of  34  psig  for  LWT.  This  change  makes  the  LH2  tank  a fail-safe 
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structure;  like  the  fail-safe  approaches  used  for  the  rest  of  the  Space  Shuttle.  This  change  realized 
a weight  savings  of  500  lb. 

Significant  weight  savings  were  also  realized  in  the  tank  major  frames,  especially  in  frame  2058 
in  the  LH^  tank.  Excellent  correlation  between  structural  testing  data  and  analysis  allowed  this  to 

happen.  Intertank  areas  that  were  tailored  to  specific  internal  loads  include  all  skin  panels,  frames, 
and  the  SRB  crossbeam.  Primary  methods  of  reduction  include  skin  panels  reduced  in  thickness,  stringers 
reduced  in  thickness  and  chem-milled;  main  frame  chords  machined  down  to  tailor  them  for  specific  loads 
and  intermediate  frame  chords  were  reduced  in  thickness. 

The  LH^  tank  structural  changes  included  added  machining  of  skin  panels,  especially  on  the  -Z  side, 
increasing  the  number  of  different  panel  types  from  21  to  30.  Also,  two  massive  LH^  thrust  longerons 

were  redesigned  to  eliminate  unnecessary  stiffeners.  Elimination  of  the  stiffeners  reduced  weight, 
improved  producibility  and  improved  the  difficult  weld  of  the  longeron  into  the  tank,  our  most  difficult 
weld.  Total  weight  savings  of  all  these  items  is  1918  lb. 

Significant  weight  reduction  was  also  realized  in  the  hardware  at  the  ET/Orbiter  interface  (struts 
and  fittings).  Margin  reductions  amounted  to  a savings  of  166  lb.  Additional  weight  reductions  occurred 
in  the  Intertank  skin-stringer  panels  and  frames.  Thicknesses  were  reduced,  resulting  in  a savings  of 
660  lb. 

FACTOR  OF  SAFETY  APPROACH 

Structure  designed  by  highly  transient  flight  events  (lift-off  and  high  "q")  will  have  a factor  of 
safety  of  1.40.  Those  structures  designed  by  steady  state  events  (max  SRB  acceleration,  post  SRB  staging, 
end  burn)  will  have  a factor  of  safety  of  1.25.  Structures  designed  by  a combination  of  the  above  will 
have  safety  factors  between  1.25  and  1.40.  Most  of  the  1312  lb  saved  by  utilizing  this  approach  came 
from  reducing  the  material  thickness  of  the  Intertank  thrust  panels,  crossbeam,  thrust  fittings,  rein- 
forced skin  panels  and  struts,  where  556  lb  were  removed.  The  LH2  tank  barrel  skins  and  frames  were 

reduced  in  thickness,  and  thrust  longerons  were  redesigned  and  lightened  resulting  in  a savings  of  618 
lb.  Interface  hardware  (struts  and  ball  fittings)  were  reduced  in  weight  by  138  lb. 


STRUCTURAL  VERIFICATION  PROGRAM 


The  primary  ingredient  in  making  the  LWT  performance  improvements  work  was  the  unique  approach  to 
structural  verification  for  the  LWT.  It  was  established  that  no  full-scale,  flight  type  structure  would 
be  provided  for  ultimate  load  testing,  as  the  structural  design  approach  was  essentially  the  same  as  for 
the  SWT.  This,  of  course,  drove  the  LWT  program  to  heavy  dependence  on  analytical  techniques  to  verify 
designs. 


STANDARD  WEIGHT  TANK  (SWT) 

Early  in  the  SWT  program,  it  was  recognized  that  if  extensive  and  continuing  structural  testing  was 
to  be  avoided,  it  would  be  necessary  to: 

1.  Establish  ultimate  strength  capability  for  flight  certification 

2.  Do  sufficient  testing  to  validate  internal  load  distributions 

3.  Do  influence  coefficient  testing  to  validate  math  models  for  analysis 

4.  Generate  a data  base  to  handle  future  load  increase  and  margin  assessments. 

The  SWT  test  program  was  established  and  completed  successfully  in  late  1979.  In  all  the  tests, 
major  emphasis  was  placed  on  determination  of  internal  loads  through  extensive  use  of  strain  instru- 
mentation, supplemented  by  deflection  and  thermal  measurements.  The  total  number  of  instrumentation 
channels  used  during  the  test  program  was  in  excess  of  7000.  Test  data  were  essentially  linear  to 
ultimate  load  levels  and  provided  satisfactory  correlation  with  analytical  predictions.  With  only  minor 
adjustments  based  on  test  data,  the  analytical  tools  were  verified  for  use  in  design  of  the  LWT. 

LIGHTWEIGHT  TANK  (LWT) 

Upon  undertaking  the  LWT  program,  a major  effort  was  made  in  using  SWT  data  to  reduce  test  require- 
ments necessary  for  LWT  certification.  Retests  were  necessary  only  in  areas  where  there  was  a signifi- 
cant configuration  change.  Wherever  configurations  were  similar  with  only  dimensional  changes,  the 
design  was  supported  by  the  verified  analytical  methods. 
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For  LWT  the  only  components  requiring  additional  validation  tests  were: 

1.  The  LH^  tank  - significant  configuration  changes  in  some  barrel  panels  and  the  STA  2058  frame 

2.  The  aft  Orbiter/ET  interface  hardware  - material  changes  and  significantly  reduced  margin  of 
safety. 

Major  changes  in  the  LWT  LH^  tank  consisted  of  removal  of  stringers  in  all  4 barrel  panels  adjacent 

to  the  ±Y  axes  and  reduced  margins  of  safety  in  the  inner  chord  of  STA  2058  frame  to  levels  below  those 

demonstrated  on  SWT. 

A series  of  development  tests  was  identified  where  the  existing  SWT  tank  could  be  modified  struc- 
turally to  simulate  the  LWT  configuration  in  the  barrel  4 area.  Stringers  were  removed  to  test  various 
stringer  spacing  effects  on  unpressurized  panel  stability.  Out-of-plane  stiffness  of  the  LWT  design 
STA  2058  frame  was  simulated  by  material  removal  of  the  inner  chord.  Wherever  possible,  original  SWT 
instrumentation  locations  were  utilized  for  correlation.  Ultimate  load  test  data  indicated  all  struc- 
ture responded  linearly  and  good  correlation  was  achieved  with  predictions  further  verifying  the 
analytical  allowables. 

As  a final  step  in  the  certification  of  the  LWT,  the  first  two  LWT  LH^  tanks  were  subjected  to  a 

series  of  special  tests  in  the  Proof  Test  Facility  at  MAF. 

LWT-1  was  instrumented  with  deflection  gages  to  support  influence  coefficient  tests  to  verify 
modeling  of  the  reduced  stiffness  STA  2058  frame. 

LWT-2  was  instrumented  with  nearly  500  strain  gages  to  support  limit  load  testing.  Tests  were 
conducted  to  verify  performance  of  barrel  panels  having  wide  stringer  spacing  and  reduced  skin  thick- 
ness, to  verify  analysis  and  performance  of  the  longeron,  barrel  panel  2 in  compression  and  STA  1871 
frame;  and  to  validate  the  redesigned  STA  2058  frame.  All  measurements  during  these  tests  were  linear 
and  agreed  very  well  with  predictions. 

Maximum  utilization  has  been  made  of  test  data  generated  during  the  SWT  and  modified  SWT  structural 
test  programs,  and  coupled  with  judiciously  selected  limit  load  testing  on  flight  hardware  has  provided 
verification  of  the  structural  modifications  made  to  establish  the  LWT  and  realize  and  exceed  the  goal 
of  6000  lb  of  performance  improvement. 


IMPLEMENTATION  STATUS 

All  engineering  has  been  released;  preliminary  design  reviews,  critical  design  reviews,  and  design 
certification  reviews  have  all  been  completed.  The  first  Lightweight  Tank  was  delivered  to  the  Kennedy 
Space  Center  in  August  1982,  and  was  flown  successfully  on  STS-6  in  April  1983. 


ET  IS  ALREADY  ACTIVE  IN  SHUTTLE  PERFORMANCE  IMPROVEMENT: 

STANDARD  WEIGHT  ET 


ET-1 

ET-2 

ET-3 

ET-4 

ET-5 

ET-6 

Specification  Weight 

78,278  LB 

78,581  LB 

77,789  LB 

77,902  LB 

77,462  LB 

77,457 

Actual  Weight 

77,099  LB 

77,249  LB 

75,770  LB 

75,895  LB 

75,172  LB 

75,453 

Performance  Improvement 

-1,179  LB 

-1,322  LB 

-2,019  LB 

-2,007  LB 

-2,290  LB 

-2,004 

LIGHTWEIGHT  ET 

LWT-1 

LWT-2 

LWT-3 

Specification  weight 

71,278  LB 

71,173  LB 

71,144  LB 

Actual  Weight 

66,824  LB 

67,009  LB 

66,809  LB 

Performance  Improvement 

-4,454  LB 

-4,164  LB 

-4,335  LB 

Figure  1.  Performance  Improvements. 
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• 1.25  SF 

• DESIGN  OPTIMIZATION 

• A/G  LINE  REMOVAL 

• TPS  TOP  COAT 

• LH2  TANK  STRINGERS 

• COMPOSITES 

• L02  SPLIT  PROOF 

• STRENGTH  DESIGN 

• 2014  A1 

• NEWLH2  TANK 
CONSTRUCTION 

• MACHINE  TPS 

• MARGIN  REDUCTION 

• FAIL  SAFE  PROOF 

• REVISED  ANALYSES 


• RESULTS  IN 
-6000  LBS. 

• 1.25  SF 

• DESIGN 
OPTIMIZATION 

• MARGIN 
REOUCTION 


Figure  3.  Weight  Savings  Screening. 


361 


ULTIMATE  SAFETY  FACTOR 


¥ \ ^1 

1 ^ 

* — — : 

: 

HIGH  a 

; 

/ BOOSTER  ACCEL. 

LIFT-OFF; 
./  1 

/ PRE/POST  STAGING 

J-L 1 

ORBITER  END  BURN  v 

1 A_ 

FLIGHT  TIME  (SEC) 

Figure  4.  A Different  F.S.  Approach. 

• MAIN  FEEDLINE  GHe  INJECTION  (ANT I -GEYSER  LINE  DELETION) 

• EFFICIENT  CROSSBEAM  IN  INTERTANK 

• lh2  TANK  STINGER/Z-FRAME  REMOVAL 

• DELETE  FIRE-RETARDANT  LATEX  PAINT  ON  TPS. 

• NEW  MATERIALS 

• MISCELLANEOUS  HARDWARE 

Figure  5.  Design  Optimization  Within  Design-To-Cost  Goals. 


Figure  6.  Main  Feedline  Injection  Saves  Weight  and  Dollars. 
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CROSS  BEAM  AFT  ET/ORB  INTERFACE  STRUCTURE 

Figure  7.  More  Efficient  Crossbeams. 


BARREL  NO.  4 NO.  3 


NO.  2 NO.  1 


STA  STA 

1130  1377 


STA  STA  STA 

1624  1871  2058 


Figure  8.  LH2  Tank  Selected  Stringer  and  Z Frame  Removals. 
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Figure  9.  New  Materials. 


MACHINE  PANELS 


AFT  INTERFACE  HARDWARE 


MACHINE 


LONGERON 


MACHINE  THRUST  STRUTS  & 
VERTICAL  STRUTS 


INTERTANK 


MACHINE 

PANELS 


LH. 


2 TANK  FRAMES 

• ADDITIONAL 
MACHINING 

• REDUCE  GAGES 
OF  WEB  AND 
STIFFENERS 


Figure  10.  Margin  Reduction  Areas. 
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ABSTRACT 


The  design  of  the  Space  Shuttle  Solid  Rocket  Booster  (SRB)  subsystems  for  reuse  posed  some  unique 
and  challenging  design  considerations  for  the  engineers  at  Marshall  Space  Flight  Center,  Alabama.  The 
separation  of  the  SRBs  from  the  Cluster  (Orbiter  and  External  Tank)  at  150,000  ft  when  the  Orbiter 
engines  are  running  at  full  thrust  meant  the  two  SRBs  had  to  have  positive  separation  forces  pushing 
them  away.  At  the  same  instant,  the  large  attachments  that  had  reacted  launch  loads  of  7.5  million 
pounds  thrust  had  to  be  severed.  These  design  considerations  dictated  the  design  requirements  for  the 
pyrotechnics  and  separation  rocket  motors.  The  recovery  and  reuse  of  the  two  SRBs  meant  they  had  to  be 
safely  lowered  to  the  ocean,  remain  afloat,  and  be  towed  back  to  shore.  To  safely  lower  a 150-ft  long, 
85  ton,  steel  cylinder  to  the  ocean  from  a 220,000-ft  free  fall  was  a design  challenge  in  every  sense. 
It  meant  the  development  and  testing  of  the  largest  parachute  recovery  system  in  use  in  the  free  world. 
The  parachutes  are  capable  of  withstanding  loads  of  300,000  lb  and  slowing  the  SRBs,  that  would  impact 
at  500  to  600  ft/sec  to  85  to  95  ft/sec. 


INTRODUCTION 


The  Space  Shuttle  concept  was  based  on  the  idea  of  reducing  the  launch  costs  associated  with 
putting  a payload  into  space.  One  means  of  reducing  launch  costs  is  to  return  as  much  of  the  launch 
vehicle  as  practical  for  a safe  Earth  landing  to  be  recycled  for  another  launch. 

NASA  has  achieved  this  objective  by  having  the  Orbiter  "fly"  back  to  Earth  from  orbit,  land  like 
an  airplane,  and  be  refurbished  for  future  launches.  Further,  NASA  decreed,  from  the  onset  of  the 
Space  Shuttle  Program,  that  the  Solid  Rocket  Boosters  would  also  be  recovered  and  reused  after  each 
launch.  Early  cost  trades  showed  that  this  approach  would  be  cost  effective  over  the  old  Saturn 
throwaway  booster  concept. 

This  SRB  reuse  concept  and  the  "piggy  back"  Space  Shuttle  design  posed  many  unique  and  challenging 
design  considerations  for  the  engineers  at  Marshall  Space  Flight  Center.  The  SRB  reuse  concept  meant 
that  a recovery  system  had  to  be  developed  that  would  safely  lower  the  free  falling  SRB  to  an  ocean 
landing  at  an  acceptable  impact  velocity.  The  "piggy  back"  Space  Shuttle  design  imposed  special  design 
requirements  on  the  pyrotechnic  separation  systems  that  were  to  be  used  on  the  Solid  Rocket  Boosters 
(SRBs). 

This  paper  will  discuss  some  of  the  structural  and  mechanical  challenges  posed  by  the  design  of  the 
pyrotechnic  and  recovery  subsystems  of  the  SRBs  to  the  engineers  and  designers  at  Marshall  Space  Flight 
Center,  Alabama. 


PYROTECHNIC  SEPARATION  SYSTEMS 


The  pyrotechnic  separation  systems  and  the  recovery  subsystems  are  closely  interrelated  in  that 
most  of  the  separation  systems1  functions  are  necessary  in  order  for  the  recovery  subsystem  to  perform 
its  function.  Figure  1 shows  a typical  launch  and  recovery  sequence  of  the  Space  Shuttle  SRBs.  At 
approximately  150,000  ft  altitude,  the  three  struts,  which  fasten  the  aft  end  of  the  SRB  to  the 
ET /Orbiter  combination,  and  the  separation  bolt,  which  fastens  the  forward  end  of  the  SRB  to  the 
External  Tank  (ET)/Orbiter  combination,  are  separated  (by  pyrotechnics).  At  the  same  time,  four 
Booster  Separation  Motors  (BSMs)  in  the  frustum  and  four  BSMs  in  the  aft  skirt  of  each  SRB  fire  to  push 
the  SRBs  away  from  the  accelerating  ET/Orbiter.  Figure  2 shows  the  relative  location  of  these  separa- 
tion systems  on  the  SRB. 

After  the  SRBs  have  coasted  up  to  an  apogee  of  220,000  to  250,000  ft,  they  free  fall  back  to 
Earth.  At  approximately  16,000  ft  altitude,  a high-altitude  baroswitch  closes  which  fires  three  nose 
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cap  thrusters  which  push  the  nose  cap  off  the  frustum.  This  event  initiates  the  parachute  sequence 
which  will  be  discussed  later.  At  approximately  9,000  ft  altitude,  a low-altitude  baroswitch  closes 
which  fires  a linear  shaped  charge  that  cuts  the  frustum  free  of  the  SRB.  This  action  allows  deploy- 
ment of  the  main  parachutes  out  of  the  frustum. 

At  approximately  1,000  ft  altitude,  a timer  in  the  forward  Integrated  Electronics  Assembly  (IEA) 
fires  an  LSC  which  separates  the  aft  60  in.  of  the  nozzle  (nozzle  extension)  from  the  nozzle.  At  water 
impact,  a "G"  switch  in  the  forward  IEA  senses  7.5  to  8.5  "g's"  and  fires  six  separation  nuts  which 
release  the  three  main  parachutes  from  the  SRB. 


SEPARATION  BOLT 


The  forward  SRB  separation  bolt  is  shown  in  Figures  3 and  4.  The  bolt  is  fabricated  of  4340  steel 
heat  treated  to  180  to  200  ksi  ultimate  tensile  strength  and  nickel  plated.  It  is  approximately  3 in. 
in  diameter  and  2 ft  long.  Launch  and  flight  loads  dictate  that  the  bolt  withstand  189,000  limit 
tension  loads  a bending  end  moment  of  55,344  in. -lb.  The  bolt  is  torqued  to  900  to  1,100  ft-lb  of 
torque.  The  bolt  has  redundant  pressure  cartridges.  At  SRB  burnout,  redundant  separation  signals  are 
sent  to  each  of  the  two  pressure  cartridges.  The  pressure  generated  by  each  cartridge  acts  against  a 
primary  piston.  This  force  is  amplified  through  compression  of  a soft  lead  coupling  and  is  transmitted 
to  the  secondary  piston.  The  force  generated  by  the  secondary  piston  reacts  against  the  secondary 
piston  of  the  redundant  side.  This  force  causes  the  bolt  housing  to  fail  in  tension  at  a pre-machined 
fracture  groove.  The  sudden  release  of  tension  plus  the  extra  margin  of  force/piston  overstroke 
accelerates  both  ends  of  the  bolt  to  approximately  100  ft/sec.  The  bolt  ends  are  contained  by  crushable 
honeycomb  installed  in  the  SRB  thrust  fitting  and  the  ET  bolt  catcher. 


SRB/ET  STRUTS 


The  aft  SRB/ET  attachment /separation  system  posed  a unique  design  challenge  in  several  areas.  The 
strut  design  had  to  accommodate  5 to  6 in.  of  relative  longitudinal  motion  between  the  SRB  and  ET,  be 
able  to  transmit  axial  loads  of  393,000  lb,  transmit  commands  from  the  Orbiter/ET  to  the  SRB,  and  be 
able  to  separate  in  a maximum  of  0.010  sec.  The  struts  had  to  be  able  to  accomplish  these  tasks  in 
severe  flight  environments.  Figure  5 shows  the  orientation  of  the  three  strut  assemblies  on  the  SRB. 

All  three  terminate  in  the  ET  attach  ring  of  the  SRB.  The  lower  strut  and  the  diagonal  strut  are 
virtually  the  same  design  and  could  be  interchangeable  while  the  upper  strut  is  considerably  more 
complex  because  it  carries  the  command  and  instrumentation  signals  across  the  ET/SRB  interface. 

During  the  stacking  operation  at  KSC,  the  ET  is  lowered  between  the  two  vertical  SRBs.  The  two 
diagonal  struts  (two  SRBs)  are  pre-adjusted  in  length  (although  all  three  struts  have  adjustment 
capability)  and  are  the  first  to  be  fastened  to  the  ET  when  it  is  resting  on  the  forward  thrust  posts 
of  the  two  SRBs.  The  upper  struts  are  the  next  system  to  be  attached  to  the  ET.  At  KSC,  the  diagonal 
and  upper  struts  are  premated  to  the  SRB  and  swung  back  out  of  the  way  in  low  bay.  The  lower  struts 
are  the  third  and  final  SRB  aft  attach  system  to  be  mated  to  the  ET  in  the  high  bay.  They  are  brought 
into  the  high  bay  as  a separate  piece  of  hardware  and  mated  to  the  "stack"  at  both  ends  — the  SRB  on 
one  end  and  the  ET  on  the  other  end. 

During  the  initial  mate,  all  three  strut  systems  must  rotate  aft  (or  down)  9.5  deg.  to  support  the 
ET  and  Orbiter  (Orbiter  and  ET  weight  is  supported  by  the  forward  thrust  post).  However,  when  the  ET 
is  loaded,  the  cryogenic  temperatures  of  the  fuel  and  oxidizer  shrink  the  ET  to  5.5  to  6 in.  and  all 
three  strut  systems  swing  up  to  a near  or  slightly  above  horizontal  position.  The  upper  strut,  in  addi- 
tion to  accommodating  these  initial  "stacking  operation"  motions,  must  be  able  to  rotate  18  to  20  deg 
(11  to  12  in.)  further  forward.  This  additional  movement  allows  the  seven  electrical  connectors  to  be 
separated  by  a more  axial  tensile  force  than  sheared  off  by  the  wiping  motion  of  the  ET  passing  by  the 
SRB  (the  strut  separation  planes  are  normal  to  the  relative  motion  of  the  SRB/ET).  All  three  strut 
systems  have  covers  which  protect  the  NSI  cables  that  connect  to  the  pressure  cartridges.  Figure  6 
shows  the  cover  configuration  for  the  lower  and  diagonal  struts.  This  cover  is  oriented  on  the  aft  side 
of  the  struts  and  protects  the  NSI  cable  from  aerodynamic  forces  and  heating  during  Space  Shuttle 
ascent.  The  NSI  cables  cross  the  separation  plane  and  are  physically  pulled  apart  by  the  motion  of  the 
SRB  leaving  the  ET.  It  requires  approximately  140  lb  of  pull  to  break  the  NSI  cables  on  the  lower  and 
diagonal  struts.  The  upper  strut  NSI  cable  crosses  the  separation  plane  through  one  of  the  seven  elec- 
trical connectors  (mentioned  earlier)  (Fig.  7). 

Because  of  the  need  to  protect  all  the  electrical  cables  passing  over  the  upper  strut,  the  upper 
strut  cover  completely  encapsulates  the  strut  (Fig.  7)  and  is  more  complex  than  the  small  covers  on  the 
lower  and  diagonal  struts.  The  large  motion  requirements  of  the  struts,  especially  the  upper  strut, 
caused  considerable  difficulty  in  designing  a Thermal  Protection  System  (TPS)  for  the  Orbiter  command 
wiring  and  NSI  cables.  The  TPS  had  to  accommodate  the  motion  and  still  prevent  hot  gas  from  reaching 
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the  cables.  No  mechanical  transition  sections  from  the  strut  to  the  ET  ring  could  be  designed  that  was 
rigid  enough  to  withstand  aerodynamic  forces  and  yet  flexible  enough  to  accommodate  the  large  angular 
excursions  of  the  strut.  The  TPS  system,  finally  derived  for  this  area,  is  basically  a "bandade" 
approach.  The  wires  are  wrapped  with  blast  tape,  then  PR  855  foam  is  used  to  fill  in  between  the  wires. 
To  protect  the  foam,  it  is  covered  with  a silicon  rubber  and  finally  with  three  to  five  layers  of  EPDM 
rubber.  It  is  desirable  to  accomplish  the  TPS  closeout  with  the  struts  in  the  launch  position  (relative 
to  the  ET  ring).  However,  this  is  not  possible  because  this  only  occurs  after  ET  fueling  at  the  launch 
pad.  Therefore,  as  much  of  the  PR  855  foam  and  silicon  rubber  are  pushed  into  the  cavity  as  possible  in 
an  effort  to  allow  the  foam  to  expand  and  fill  the  gap  left  by  the  upward  motion  of  the  struts  during 
ET  filling.  The  whole  TPS  closeout  process  on  the  struts  is  extremely  time  consuming  and  cumbersome 
and  will  undoubtedly  become  an  assembly  "tent  pole"  as  Shuttle  launch  rates  increase. 


SEPARATION  MOTORS 


Each  SRB  has  eight  Booster  Separation  Motors  (BSMs)  which  fire,  simultaneously,  with  the  thrust 
post  bolt  and  the  strut  separation  initiators.  These  separation  motors  (four  aft  and  four  forward)  fire 
for  a nominal  0.7  sec  and  produce  20,000  lb  thrust  each  (Fig.  8).  The  four  forward  BSMs  are  mounted  in 
the  frustum  and  canted  inward  toward  the  Orbiter  and  have  their  nozzle  pointed  forward  (upward  when 
sitting  on  the  launch  platform),  their  thermal  shield  design  is  rather  complex.  The  thermal  shield  is 
required  to  insure  that,  during  ascent,  no  hot  gaseous  flow  funnels  down  the  nozzle  and  impinges  on  the 
propellant.  If  this  were  to  happen,  the  motor  could  be  auto-ignited  by  this  phenomena.  Also,  because 
of  the  possible  Orbiter  debris  problem,  the  forward  BSM  thermal  shield  design  had  to  insure  that  no 
debris  would  be  generated  at  the  time  of  BSM  firing.  This  problem  does  not  exist  with  the  aft  BSMs 
because  they  are  aft  of  the  Orbiter  and  pointed  away  from  the  Orbiter  wings/tiles.  The  thermal  shield 
design  for  the  forward  BSMs  looks  and  functions  like  a hinged  cover  or  door.  The  hinge  pin  is  actually 
yielded  in  torsion  by  the  opening  of  the  door.  In  this  way,  the  kinetic  energy  of  the  door  is  changed 
into  heat  energy  by  the  yielding  of  the  hinge  pin  (Fig.  9).  Thus,  the  door  is  retained  (i.e.,  no 
debris).  Further,  a ratchet  latching  mechanism  insures  that  the  door  will  not  inadvertently  swing 
closed  after  opening.  The  aft  BSM  thermal  shields  (covers)  are  not  nearly  as  complex  and  are  blown  off 
at  BSM  ignition  (Fig.  10).  Because  of  the  location  of  one  of  the  skirt  support  posts,  it  was  necessary 
to  place  one  of  the  four  aft  BSMs  by  itself  on  the  opposite  side  of  the  post  structure  (Fig.  11).  The 
separation  motor  system  and  the  structural  separation  system  are  initiated  simultaneously.  Redundant 
separation  signals  to  the  forward  and  aft  separation  motor  systems  initiate  redundant  NSI  detonators. 

The  detonation  shock  from  the  NSI  detonators  propagates  through  two  CDF  manifold  and  eight  CDF  assem- 
blies to  eight  CDF  initiators  mounted  in  the  separation  motors  (Fig.  12). 


NOSE  CAP  THRUSTERS 


The  nose  cap  separation  system  is  activated  by  the  high  baroswitch  at  approximately  16,000  ft. 
Because  the  nose  cap  encapsulates  the  drogue  parachute/pilot  parachute  packs,  the  nose  cap  must  be 
pushed  off  with  a minimum  of  80  ft/sec  to  clear  the  parachutes  during  nose  cap  deployment.  The  thruster 
(Fig.  13)  consists  of  a small  piston  inside  a cylinder  that,  using  the  gaseous  pressure  produced  by  the 
pressure  cartridge,  produces  a 30,000-lb  thrust  over  a 6-in.  stroke.  At  the  end  of  the  6-in.  stroke, 
the  piston  rod  separates  from  the  piston  and  is  ejected  with  the  nose  cap.  Since  the  nose  cap  separa- 
tion system  is  not  man  rated  (i.e.,  is  not  required  to  function  during  ascent  for  mission  success),  it 
is  a simplex  system  (Fig.  14).  The  thruster  serves  a dual  purpose  in  that  a 0.5-in. -diameter  bolt 
screws  into  the  piston  body  to  fasten  the  nose  cap  structure  to  the  frustum.  To  achieve  this  purpose, 
the  thruster  has  a shear  flange  that  will  withstand  a static  tension  load  of  10,000  lb  applied  through 
the  0.5-in.  nose  cap  holddown  bolt's  longitudinal  axis  prior  to  actuation.  The  thruster  will  also  with- 
stand a torque  of  1,000  in-lb  applied  to  the  0.5-in.  holddown  bolt.  The  shear  flange  is  sheared  by  the 
upward  movement  of  the  piston  during  actuation.  The  majority  of  the  thruster  components  (body,  piston, 
piston  rod,  etc.)  is  4340  steel. 


SRB/FRUSTUM  SEPARATION  RING 


The  frustum  separation  system  consists  of  one  NSI  detonator,  one  CDF  assembly,  and  one  frustum 
separation  assembly  (Fig.  15).  During  descent,  as  the  SRB  passes  through  approximately  6,000  ft,  the 
low  altitude  barometric  switch  sends  a fire  command  to  the  frustum  separation  pic.  The  pic  initiates 
an  NSI  detonator  located  in  the  top  ring  of  the  forward  skirt.  The  output  of  the  detonator  is  prop- 
agated through  the  CDF  assembly  which  detonates  the  Linear  Shaped  Charge  (LSC)  in  the  detonator  block 
assembly.  The  detonator  block  assembly  LSC  detonates  the  LSC  in  the  frustum  separation  assembly.  The 
30  grains/ft  HMX  Jetcord  detonates  at  7,000  m/sec  and  severs  the  0.215  thick  2219  aluminum  separation 
ring  and  releases  the  frustum  from  the  forward  skirt/SRB. 
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MAIN  PARACHUTE  SEPARATION  NUT 


The  main  parachute  separation  system  consists  of  six  separation  nuts  (Fig.  16)  which  are  mounted 
to  the  underside  of  the  forward  skirt  401  ring.  A 1.25-in. -diameter  bolt  fastens  the  main  parachute 
attach  fitting  to  the  upper  side  of  the  401  ring,  passes  through  the  ring,  and  threads  into  the  separa- 
tion nut. 

At  splashdown,  a MGM  switch  located  in  the  forward  IEA  of  the  SRB  closes  which  issues  a fire 
command  through  the  recovery  logic  to  the  main  parachute  disconnect  pic.  The  pic  ignites  an  NSI 
detonator  (Fig.  17)  whose  detonation  is  propagated  through  a CDF  manifold,  and  six  CDF  assemblies  to  six 
CDF  initiators  installed  in  each  of  the  six  separation  nuts  attaching  the  three  main  parachutes  to  the 
SRB  (there  are  two  separation  nuts  per  main  parachute).  When  fired,  these  initiators  pressurize  the 
separation  nut  causing  the  case/collet  ring  to  slide  back  opening  the  collet  and  releasing  the  main 
parachute  attach  bolt  (Fig.  18).  The  attach  bolt  is  ejected  from  the  separation  nut  by  the  ejector 
piston  and  the  tension  in  the  main  parachute  links.  The  separation  nuts  are  presently  designed  for  a 
parachute  bolt  tension  of  135,000  lb  and  a bolt  torque  of  750  to  800  ft-lb. 


RECOVERY  SUBSYSTEM 


Each  SRB  contains  a Recovery  Subsystem  which  consists  of  five  parachutes  and  associated  support/ 
attachment  and  deployment  hardware  (Fig.  19).  All  of  the  parachutes  are  ribbon  construction  made  of 
nylon  webbing,  are  20  deg  conical  geometry,  and  have  16%  geometric  porosity.  All  five  of  the  para- 
chutes are  contained  in  the  SRB  nose  cone.  The  nose  cone  consists  of  a 75-in.  tall  nose  cap  forward 
section  and  a 120-in.  tall  frustum  aft  section.  The  nose  cap  houses  the  pilot  and  drogue  parachutes 
while  the  frustum  contains  the  three  main  parachutes.  The  frustum  also  contains  the  high  and  low 
altitude  baroswitches  described  earlier.  As  might  be  expected  of  a Recovery  (parachute)  systpm  that  is 
designed  to  decelerate  an  85-ton  150-ft-long  cylinder,  that  is  falling  at  about  600  ft /sec,  all  of  the 
parachutes  are  of  heavy  duty  construction.  The  pilot  parachute  is  11.5  ft  in  diameter  and  has  a design 
limit  load  of  14,500  lb.  It  has  a 50-ft  trailing  distance.  It  is  deployed  by  the  nose  cap  which  has 
been  ejected  from  the  SRB  by  three  piston  thrusters  at  80  to  90  ft/sec.  The  pilot  parachute  has  16 
gores  (i.e.,  16  suspension  lines),  weighs  42  lb  packed',  and  is  attached  to  the  top  of  the  drogue 
parachute  pack. 

The  drogue  parachute  is  54  ft  in  diameter  and  has  60  gores.  It  has  two  reefing  stages  (i.e., 
reefing  lines)  with  two  reefing  cutters  placed  180  deg  apart  on  each  reefing  line.  The  design  limit 
load  of  the  drogue  is  270,000  lb  and  its  construction  is  massive.  A few  design  details  will  illustrate 
this  as  follows:  The  radials  are  made  of  4 plies  of  4,000-lb  strength  nylon  webbing,  the  60  suspension 
lines  are  each  made  of  1 ply  of  150,000-lb  webbing,  the  reefing  lines  are  made  of  3 plies  of  12,000-lb 
webbing,  the  horizontal  ribbons  are  1,000-,  1,500-,  and  2,000-lb  webbing,  etc.  The  drogue  parachute 
pack  weighs  1,270  lb.  The  function  of  the  drogue  parachute  is  to  rotate  the  descending  SRB  into  a tail 
first  orientation  so  that  the  cluster  of  three  main  parachutes  can  be  deployed  and  the  risks  of  their 
entanglement  are  minimal.  The  drogue  parachute  slows  the  SRB,  and,  when  the  low  altitude  baroswitch 
closes,  provides  the  necessary  force  for  main  parachute  deployment.  The  drogue  parachute  canopy  trails 
the  SRB  by  105  ft  and,  when  the  frustum  is  released  from  the  SRB,  extracts  the  main  parachutes  (lines 
first)  out  of  their  deployment  bags. 

Each  main  parachute  is  115-ft  in  diameter  and  has  96  gores.  Like  the  drogue,  they  have  two  reefing 
stages  (i.e.,  reefing  lines)  with  two  reefing  cutters  placed  180  deg  apart  on  each  reefing  line.  The 
design  limit  load  of  each  main  is  about  174,000  lb.  The  radials  on  each  canopy  are  made  of  two  plies 
of  3,000-lb  webbing,  the  96  suspension  lines  are  made  of  6,000-lb  webbing,  each  reefing  line  is  made  of 
two  plies  of  9,000-lb  webbing,  and  the  risers  and  dispersion  bridles  consist  of  6 plies  of  15,000-lb 
webbing.  Each  main  parachute  pack  weighs  about  1,700  lb.  The  function  of  the  three  main  parachutes 
is  to  decelerate  the  SRB  to  an  acceptable  water  impact  terminal  velocity  (about  85  to  90  ft/sec)  and 
then  release  from  the  SRB  and  be  retrieved  from  the  ocean  by  retrieval  vessels. 


PARACHUTE  DEPLOYMENT  SEQUENCE 

The  typical  deployment  sequence  is  shown  in  Figures  20  and  21.  At  approximately  16,000  ft  the 
sequence  is  initiated  by  the  high  baroswitch  as  discussed  earlier.  The  nose  cap  deploys  the  pilot 
chute  whose  function  it  is  to  deploy  the  drogue  parachute.  Early  studies  concluded  that  the  nose  cap 
did  not  have  sufficient  energy  to  deploy  the  drogue  under  all  deployment  conditions.  After  the  pilot 
bag  has  moved  about  8 ft,  zero  time  delay  cutters  (100  msec)  are  initiated  to  release  the  drogue  pack 
restraint  straps.  The  pilot  parachute  inflates  and  pulls  the  drogue  bag  from  the  SRB.  The  drogue 
parachute  is  then  deployed  lines  first.  The  pilot  parachute  and  drogue  bag  are  one-use  items  and  are 
not  recovered. 
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At  drogue  deployment,  the  angle  of  attack  of  the  SRB  is  between  8u  and  140  deg.  The  function  of 
the  drogue  is  to  rotate  the  falling  SRB  into  a tail  first  orientation  and  reduce  its  velocity  so  that 
the  cluster  of  three  main  parachutes  can  be  deployed  with  minimum  risk  of  deployment  damage,  entangle- 
ment or  excessive  loads.  The  drogue  also  provides  the  force  required  to  deploy  the  main  parachutes 
liner  first  from  the  frustum.  After  the  main  parachutes  are  stripped  from  their  deployment  bags,  the 
drogue  parachute,  frustum  and  main  parachute  deployment  bags  continue  to  water  impact  and  are  retrieved 
for  reuse. 

The  function  of  the  three  main  parachutes  is  to  decelerate  the  SRB  to  an  acceptable  water  impact 
velocity  of  85  to  90  ft/sec.  In  the  initial  concept,  the  main  parachutes  were  released  from  the  SRB 
at  water  impact  to  facilitate  retrieval  of  both  the  SRB  and  the  main  parachutes. 

The  large  recovery  weight  (160,000  to  170,000  lb)  and  the  ocean  landing  of  the  SRBs  posed  some 
interesting  design  challenges  for  the  Recovery  Subsystem  designers.  A list  of  a few  of  these  design 
challenges  is  as  follows: 

Pilot/drogue  deployment. 

Drogue  loads  measurement. 

Main  parachute  flotation/energy  absorbers. 

Main  loads  measurement. 

Each  of  these  "design  challenges"  will  be  briefly  addressed  in  this  paper. 


PILOT/DROGUE  DEPLOYMENT 


As  stated  earlier,  because  of  the  need  of  deployment  condition  flexibility  (deployment  dynamic 
pressure  of  127  to  340  lbs/ft2,  SRB  pitch  attitudes  of  70  to  140  deg,  and  SRB  roll  rates  of  0 to  135 
deg/sec),  the  decision  was  made  to  use  a pilot  parachute  to  insure  a repeatable,  orderly,  drogue  para- 
chute deployment. 

Figure  20  shows  the  deployment  sequence  of  the  nose  cap  pilot /drogue.  The  pilot  bag  is  connected 
to  the  base  of  the  nose  cap  by  a three-legged  bridle  system.  In  order  to  limit  the  loads  into  the  nose 
cap  interface  attach  point  and  the  pilot  parachute  bag,  a method  of  absorbing  the  shock  caused  by  the 
relative  velocity  between  the  nose  cap  and  pilot  parachute  had  to  be  devised. 

Rip  stitch  type  energy  absorbers  (Fig.  22)  were  developed  by  which  shock  loads  could  be  controlled 

by  varying  the  number  of  piles  and  the  stroke  of  the  energy  absorbers  could  be  controlled  by  varying 

the  number  of  bight  elements.  After  many  static  and  dynamic  development  tests  using  various  parent 

material  fabrics,  stitch  patterns,  thread  strength  and  material,  the  selected  configurations  consist  of 

6,500  lb  strength  nylon  MIL-W-4088  TY  XIII  with  a modified  six -point  stitch  using  eight  cord  thread. 

Initially,  we  experienced  problems  of  the  parent  material  failing  rather  than  the  stitches  failing. 

We  noted  that  if  the  first  stitch  failed,  the  remainder  failed  in  an  orderly  fashion  with  minimal 
damage  to  the  parent  material,  the  desired  result.  Initial  test  success  was  achieved  by  simply  cutting 
the  first  stitch  in  each  point  of  each  bight.  Later  it  was  determined  that  the  same  results  could  be 

obtained  by  lifting  the  needle  on  the  sewing  machine  at  the  end  of  each  point  stitch  pattern  and  moving 

it  laterally  a small  amount  before  returning  back  along  the  bight.  The  selected  configuration  produces 
730  ± 230  lb  per  ply  and  1 ft  of  stroke  per  bight.  A three-ply,  10-bight  configuration  is  used  to 
connect  the  nose  cap  to  the  pilot  parachute  bag  (Fig.  23).  A 12-ply,  8-bight  configuration  of  the  same 
basic  design  is  used  to  connect  the  main  parachute  floats  to  the  apex  of  the  main  parachutes  (discussed 
later) . The  momentum/aero  drag  of  the  nose  cap  provides  the  force  necessary  to  break  the  cotton  ties 
that  fasten  the  pilot  bag  to  the  top  of  the  drogue  bag.  As  the  pilot  bag  leaves  the  drogue  pack,  cotton 
ties  break  allowing  the  pilot  to  deploy  lines  first  out  of  the  bag.  A drogue  bag  restraint  loop  passes 
through  loops  in  the  end  of  six  drogue  bag  restraint  straps  and  through  two  redundant  reefing  cutters. 
The  other  end  of  the  six  restraint  straps  attach  to  ratchet  fittings  on  the  frustum  top  deck  to  hold 
the  drogue  pack  onto  the  frustum  (i.e.,  SRB)  until  the  restraint  loop  is  cut  by  either  of  the  two 
cutters.  The  two  cutters  are  zero  time  cutters,  i.e.,  they  fire  within  100  msec  after  their  firing  pin 
is  pulled.  The  first  8 ft  of  motion  of  the  pilot  bag  provides  this  pulling  motion.  A lanyard  from 
the  pilot  bag  is  fastened  to  the  firing  pin  of  the  cutters.  As  the  pilot  bag  leaves,  the  lanyard 
becomes  taut  and  pulls  the  cutter  firing  pins.  We  recognized  a potential  problem:  after  the  two 
cutters  had  performed  their  function  (i.e.,  they  had  cut  the  restraint  loop),  they  would  be  unrestrained 
and  flying  freely.  Because  of  their  size  and  mass  (2  lb),  they  would  be  potential  "bullets"  and  could 
pass  through  the  drogue  canopy.  If  they  severed  a major  struct»,T*al  member  (vent  line,  radial,  or  sus- 
pension line),  total  loss  of  the  SRB  could  result.  This  potential  problem  was  averted  by  providing 
another  lanyard  to  assure  that  the  cutters  would  remain  attached  to  the  drogue  deployment  bag. 
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DROGUE  DECK  FITTING/LOAD  PINS 


At  the  time  of  drogue  deployment,  the  SRB  may  at  any  angle  of  attack  from  80  to  140  deg  with  pitch 

and  yaw  rates  of  15  deg/sec  and  a roll  rate  up  to  135  deg/sec.  The  deck  fittings  therefore  must 

accommodate  loads  in  any  direction  and  allow  changes  in  direction  as  the  SRB  is  stabilized  in  a nozzle- 
first  attitude.  A double  clevis  arrangement  shown  in  Figure  24  shows  the  selected  configuration. 

Twelve  of  these  fittings  (each  holding  five  suspension  lines)  react  the  drogue  loads  into  the  frustum. 

At  the  high  roll  rates  possible  at  drogue  deployment,  the  possibility  of  the  suspension  lines 
twisting  into  a node  and  causing  them  to  rub  against  each  other  as  the  SRB  swings  back  and  forth  (pitch 

and  yaw)  was  of  some  initial  concern.  A swivel  attachment  between  the  drogue  and  SRB  was  considered. 

However,  the  physical  size  required  to  react  270,000  lb,  plus  the  tendency  of  bearings  to  lock  up  due 
to  rapid  load  onset  and  the  large  increase  in  loads  to  individual  fittings  resulting  from  a confluence 
point  in  the  drogue  suspension  lines  caused  the  swivel  concept  to  be  discarded.  Also,  analysis  showed 
that  the  rubbing  force  of  the  suspension  lines,  the  relative  velocity  between  suspension  lines  and  the 
small  number  of  cycles  were  all  low  enough  to  present  a low  risk.  To  date,  after  six  drop  tests  and 
six  Shuttle  flights  (12  SRBs),  no  suspension  line  damage  due  to  twisting  has  been  observed.  The  first 
development  air  drop  test  gave  an  indication  of  significant  galling  at  the  point  contact  of  the  4340 
steel  clevises.  An  application  of  dry  film  lube  on  the  rubbing  surfaces  has  eliminated  this  problem. 

The  requirement  to  measure  drogue  loads  during  both  development  air  drop  tests  and  the  first  six 
Space  Shuttle  flights  presented  a unique  challenge.  Because  of  the  symmetry  of  the  twelve  drogue  attach 
points  and  the  limitation  of  data  channels,  six  of  the  fittings  were  instrumented.  The  concept  of 
standard  load  cells  placed  in  the  suspension  line  was  discarded  because  of  the  difficulty  of  assuring 
that  they  would  not  "bang"  into  each  other  during  deployment  and  possible  twisting  of  the  lines  and  the 
expected  problems  of  protecting  the  wires  leading  from  the  load  cells  to  the  frustum  deck.  The  severe 
rotation  and  chafing  environment  of  the  clevises  precluded  putting  strain  gages  on  the  fittings  and 
there  were  not  enough  data  channels  available  to  instrument  the  four  bolts  on  each  fitting.  The  obvious 
choice  remaining  was  the  pin  that  fastens  the  drogue  suspension  line  spool  to  the  deck  fitting  shackle. 
Several  instrumentation  personnel  advised  against  instrumenting  a pin  in  bending  because  of  lack  of 
repeatability  due  to  pin  clocking  and  fulcrum  shift  during  loading.  The  final  load  pin  design  is  shown 
in  Figure  25.  Strain  gages  are  applied  to  the  machined  "neck"  of  the  pin.  Collars  are  then  pressed 
on  to  each  end  with  a tolerance  of  ± 0.0002  in.  The  spacing  between  the  ends  of  the  upper  shackle  is 
controlled  by  placing  a spreader  tube  between  the  clevis  legs.  Clocking  accuracy  (and  pin  retention) 
was  accomplished  by  drilling  the  flange  at  one  end  of  the  pin  and  fastening  it  to  the  shackle  by  a 
screw.  Once  the  unit  is  calibrated  to  a load  of  35,000  lb,  the  shackle,  pin  and  spreader  tube  remain 
as  a unit  until  flight,  so  that  the  configuration  flown  is  identical  to  the  one  calibrated.  These 
drogue  pins  have  proven  very  reliable  and  accurate.  Only  three  drogue  load  measurements  out  of  72  pins 
have  been  lost  on  the  first  six  Shuttle  flights  (no  measurements  were  available  from  STS-4  due  to  SRB 
loss,  but  the  retrieved  drogue  load  cells  were  intact).  Load  accuracy  of  ±3%  with  1%  repeatability 
have  been  achieved. 


MAIN  PARACHUTE  FLOTATION /ENERGY  ABSORBERS 


The  expense  of  the  large  heavy  duty  parachutes  dictated  that  they  be  retrieved  for  reuse.  The 
original  End  Item  Specification  stated  that  access  to  the  parachute  apex  be  provided  because  riser-first 
retrieval  causes  the  parachute  to  inflate  under  water  and  act  as  a sea  anchor.  The  drogue  parachute 
remains  attached  to  the  frustum.  Access  to  the  apex  is  provided  by  a long  (175  ft)  retrieval  line 
supported  by  a small  peanut  float  for  easy  location  and  retrieval. 

The  initial  recovery  concept  called  for  the  main  parachutes  to  separate  from  the  SRB  at  water 
impact  and  therefore  had  to  be  self  supporting.  Floats  (Figs.  26  and  27)  were  attached  to  the  apex  of 
the  main  parachutes  through  12-ply  8-bight  energy  absorbers  (discussed  earlier).  The  load  from  the 
floats  acquired  limiting  for  two  reasons:  (1)  to  avoid  structural  damage  to  the  float  bags  and  main 

parachute  vent  lines  and  (2)  to  limit  the  acceleration  of  parachute  location  aid  (PLA)  that  was 
originally  to  be  housed  in  the  float.  The  PLA  was  never  developed.  The  development  air  drop  program 
confirmed  our  concern  that  retaining  the  f lotation/PLA  system  in  the  dynamic  environment  of  main 
parachute  deployment  would  be  difficult.  During  the  first  three  drops,  the  PLA  mass  simulator  nor  the 
flotation  foam  could  be  retained.  After  redesigning  the  float  and  float  bridle,  the  floats  on  drop 
tests  4,  5,  and  6,  with  various  degrees  of  float  bag  damage,  were  retained.  Due  to  the  uncertainty  of 
PLA  requirements  and  the  limitation  of  funds  for  the  drop  test  program,  only  one  parachute  on  drop 
No.  5 tested  the  actual  configuration  used  on  the  Shuttle  flights.  On  the  first  Shuttle  flight,  two 
parachutes  sank  because  of  loss  of  flotation  foam.  On  the  second  Shuttle  flight,  no  parachutes  were 
lost  even  though  no  design  change  was  made.  Examination  of  the  float  bag  revealed  the  marginal  nature 
of  the  bag  design.  Before  flight  three  (STS-3)  the  float  bag  was  strengthened.  During  STS-3,  the 
floats  of  two  chutes  became  entangled  causing  the  failure  of  one  chute.  A program  decision  was  then 
made  to  leave  the  parachutes  attached  to  the  SRB.  On  STS-4,  the  separation  nut  on  one  of  two  main 
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chute  attach  fitting  was  deactivated.  Due  to  premature  activation  of  the  active  separation  nuts,  both 
SRBs  were  lost.  On  STS-5  and  STS-6  and  for  the  forseeable  future,  the  main  parachutes  will  remain 
attached  to  the  SRB  until  the  retrieval  crew  detaches  them.  If  an  improved  separation  nut  design  and 
software  is  developed,  a deck-mounted  flotation  system  will  be  developed  to  again  allow  separation  of 
the  main  parachutes  at  impact. 


MAIN  PARACHUTE  LOAD  MEASUREMENT 


Each  of  the  three  main  parachutes  are  attached  to  the  SRB  at  two  attach  points.  The  total  of  six 
attach  points  are  equally  spaced  around  the  circumference  of  the  forward  skirt.  Load  measurement  for 
the  main  parachute  attach  fitting  presented  a different  challenge.  These  fittings  were  designed  for  a 
load  of  125,000  lb.  Since  the  SRBs  might  still  be  rolling  and  swinging  at  main  chute  deployment,  and 
to  accommodate  changes  in  pull  angle  resulting  from  the  different  inflated  stages  of  the  main  parachutes, 
the  fittings  were  required  to  articulate  in  two  planes  to  assure  pure  tension  measurements  (Fig.  28). 
Radial  articulation  was  provided  by  means  of  a yoke  attached  to  the  fixed  portion  of  the  fittings  bolted 

to  the  SRB.  Tangential  articulation  was  provided  by  pinning  to  the  upper  portion  of  yoke,  the  two 

plates  that  carried  the  loads  from  the  four  bolts  through  the  risers  to  the  yoke  of  the  deck  fittings. 
Since  these  plates  are  the  only  component  reacting  pure  parachute  riser  tension  loads,  this  was  the 
logical  place  to  locate  the  load  cells.  In  order  to  control  the  attitude  and  restrict  the  motion  of  the 

articulated  attach  fittings,  shear  bolts  were  placed  through  the  yoke  and  fixed  deck  fittings  and  tangs 

on  the  plates  were  forced  against  the  fixed  fittings.  This  approach  held  the  total  assembly  rigid  until 
the  bolts  were  sheared  at  main  parachute  line  stretch.  In  order  to  avoid  bending  stresses  in  the  instru- 
mented plates,  the  four  bolts  that  pass  through  the  spreader  plates  and  spools  were  carefully  torqued 
and  a feeler  gage  measurement  was  made  between  the  plate  and  spools.  Also,  once  the  unit  was  calibrated, 
all  components  remain  together.  A standard  load  cell  was  considered  for  this  application,  but  125,000 
lb  capacity  load  cells  are  quite  large  and  supporting  any  hardware  from  the  SRB  forward  skirt  dome  was 
not  allowed.  Therefore,  the  problem  of  cantilevering  such  large  load  cells  from  the  deck  fittings  was 
avoided  by  using  the  selected  configuration. 

The  main  parachute  attach  fittings,  the  drogue  load  pins  and  the  drogue  deck  fittings  were  all 
initially  intended  for  single  usage.  The  drogue  deck  fittings  have  been  tempered  from  a maximum  tensile 
strength  of  180,000  lb  to  160,000  lb  and  are  certified  for  multiple  reuse  providing  they  pass  proof  test 
and  magnetic  particle  inspections.  The  main  chute  deck  fittings  and  drogue  load  pins  have  been 
refurnished  and  certified  for  a second  use. 


CONCLUSION 


This  paper  has  discussed  some  of  the  more  significant  design  challenges  raised  by  the  initial 
specification  requirements.  Now  that  the  developmental  flights  (STS-1  through  STS-6)  have  flown,  how 
well  these  challenges  have  been  met  can  be  assessed. 

In  general,  both  the  pyrotechnic  and  recovery  subsystems  have  met  or  exceeded  design  requirements. 
In  twelve  vehicles,  there  has  only  been  one  instance  where  the  pyrotechnic  system  has  failed  to  function 
properly.  That  was  on  STS-4  when  a 7.5  g ”6"  switch  sensed  the  design  7.5  g's  from  the  pyrotechnic 
shock  propagated  by  the  frustum/ SRB  linear  shaped  charge  and  fired  the  main  parachute  separation  nuts 
and  released  the  parachutes  before  they  could  function.  Since  STS-4,  the  parachutes  have  been  attached 
to  the  SRB’s  by  structural  nuts. 

The  recovery  subsystem  has  had  some  anomalies  occur  because  of  the  requirement  for  the  parachutes 
to  be  separated  from  the  SRB  at  water  impact  and  be  self  floating.  This  buoyancy  requirement  requires 
flotation  be  added  to  the  parachutes.  This  flotation  has  caused  the  following  anomalies:  On  STS-1, 

two  parachutes  "drowned"  because  the  flotation  was  torn  off  during  parachute  deployment  and  the  para- 
chutes sank.  On  STS-3,  the  floats  of  two  parachutes  became  entangled  and  caused  the  failure  of  one  of 
the  parachutes.  Since  STS-4,  the  decision  was  made  to  leave  the  parachutes  attached  to  the  SRBs,  and 
we  have  had  no  parachute  failures  since.  The  drogue  parachute  has  always  been  subjected  to  loads  above 
design  limit  on  each  Space  Shuttle  flight,  and  no  major  structural  damage  has  been  noted.  One  of  the 
two  remaining  STS-3  main  parachutes  saw  loading  34%  above  design  limit  and  again  no  major  structural 
damage  was  noted. 

Presently,  larger  main  parachutes  (136-f t-diameter)  are  under  development  to  slow  the  SRBs  to 
75  ft/sec  to  lessen  water  impact  damage.  We  expect  no  major  problems  with  this  development  based  on 
our  experience  with  the  existing  design. 
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Figure  1.  Solid  Rocket  Booster  Recovery  Sequence 
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Figure  3.  Forward  SRB/ET  Separation  System. 


373 


THREAD  END 


SECONDARY  PISTONS 
(MARAGING  STEEL) 


,0-RING 


f 


FRACTURE  GROOVE 
SEPARATION 
PLANE 


3.4575-12  UNJS-3A 


Figure  4.  Forward  SRE/ET  Separation  Bolt. 
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Figure  6.  SRB/ET  Aft  Separation  System,  Lower  and  Diagonal  Struts. 
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Figure  7.  SRB/ET  Aft  Separation  System  (Upper  Strut). 
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Figure  9.  SRB  Forward  Booster  Separation  Motors. 
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Figure  11.  SRB  Aft  Booster  Separation  Motors. 
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Figure  12.  SRB  Forward  Booster  Separation  Motor  (BSM)  Ignition. 


Figure  13.  Nose  Cap  Separation  Thruster. 
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Figure  14.  SRB  Nose  Cap  Separation. 
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Figure  15.  SRB  Forward  Separation  Ring  Cross  Section. 
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Figure  16.  Main  Parachute  Release  System. 


Figure  17.  Main  Parachute  Release  System 
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Figure  19.  SRB  Decelerator  Subsystem  Installed. 
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Figure  20.  Deployment  Sequence,  Pilot  Chute. 
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Figure  21.  Deployment  Sequence,  Drogue/Main  Chute. 
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Figure  22.  Energy  Absorber  Pretest  Configuration. 
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Figure  24.  Drogue  Riser  Attach  Fittings. 
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Figure  25.  Drogue  Load  Cell. 


Figure  26.  SRB-DBS  Main  Chute  Deployment  Sequence. 
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Figure  27.  Main  Parachute  Float  and  Retrieval  Provisions. 
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SSME  LIFETIME  PREDICTION  AND  VERIFICATION,  INTEGRATING 
ENVIRONMENTS,  STRUCTURES,  MATERIALS;  THE  CHALLENGE 
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Marshall  Space  Flight  Center 
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ABSTRACT 


The  planned  missions  for  the  Space  Shuttle  dictated  a unique  and  technology-extending  rocket 
engine.  The  high  ISp  (performance)  requirements  in  conjunction  with  a 55-mission  lifetime,  plus 
volume  and  weight  constraints,  produced  unique  structural  design,  manufacturing,  and  verification 
requirements.  Operations  from  earth  to  orbit  produce  severe  dynamic  environments,  which  couple  with 
the  extreme  pressure  and  thermal  environments  associated  with  the  high  performance,  creating  large 
low  cycle  loads  and  high  cycle  alternating  stresses  above  endurance  limit  which  result  in  high 
sensitivity  to  alternating  stresses.  Combining  all  of  these  effects  resulted  in  the  requirement  for 
exotic  materials,  which  are  more  susceptible  to  manufacturing  problems,  and  the  use  of  an  all -welded 
structure.  This  paper  discusses  the  challenge  of  integrating  environments,  dynamics,  structures,  and 
materials  into  a verified  SSME  structure  to  meet  a 55-mission  lifetime  while  producing  unprecedented 
performance.  Included  also  are  the  verification  program  and  developmental  flight  results.  Rocketdyne 
Division  of  Rockwell  International  Corporation,  under  contract  to  Marshall  Space  Flight  Center,  is  the 
prime  contractor  for  the  development  of  the  Space  Shuttle  Main  Engine  (SSME). 


INTRODUCTION 


The  Space  Shuttle  mission  requirements  and  the  resulting  propulsion  system  requirements  have  led 
to  very  stringent  and  technology-extending  structural  design,  verification,  manufacturing,  and 
operational  approaches.  Being  a manned  vehicle,  Space  Shuttle  dictated  that  the  engine  be  of  the 
highest  possible  reliability  (References  1 and  2). 

The  Space  Shuttle  missions  require  the  engine  to  have  hi qh  performance  ISp  of  455  seconds,  a 
thrust  of  375,000  pounds  (sea  level),  long  life  (55  missions),  minimum  maintenance,  and  to  be  achieved 
within  stringent  weight  and  volumetric  constraints.  These  concepts  and  requirements  led  to 
a new  approach,  "line  replaceable  units  (LRU's),"  that  could  be  installed  either  in  the  field  or 
factory.  Acceptance  and/or  verification  of  LRU's  are  accomplished  separately  from  the  engine  system 
(Reference  3). 

In  order  to  achieve  the  high  performance  (Isp)»  a two-stage  pump  system  is  used  in  conjunction 
with  preburners  which  burn  the  fuel  rich,  furnishing  the  power  for  the  pumps.  This  extremely  hot  fuel 
rich  gas  feeds  the  main  combustion,  efficiently  developing  the  engine  thrust.  This  system  results  in 
unprecedented  operating  regimes  of  temperatures,  pressures,  and  rotating  machinery  speeds.  The  high 
rotary  speeds  and  the  combustion  processes  create  mechanical,  acoustical,  and  fluctuating  pressure 
environments.  Figure  1 is  a schematic  showing  typical  pressures  and  temperatures.  The  volumetric 
and  weight  constraints  drive  the  design  toward  a high  concentration  of  energy  and  minimum  structure 
sizing  (thickness,  etc.).  The  energy  concentration  can  be  illustrated  by  observing  the  size  of  the 
high  pressure  fuel  pump,  which  generates  70,000  horsepower  within  an  envelope  18  inches  in  diameter 
by  30  inches  long  and  rotates  at  speeds  up  to  approximately  40,000  rpm  (References  1,  2,  4,  5,  6,  7,  8, 
and  9). 

The  structural  design  problem  is  further  complicated  by  the  multivaried  operating  regime 
(throttling  to  65%)  and  the  requirement  to  gimbal  the  engine  ± 10  degrees  at  a 10  degree/second  rate 
for  vehicle  control  authority.  The  engine  starts  on  the  ground,  operates  in  the  atmosphere  and  then 
in  a vacuum,  and  shuts  down,  producing  large  thermal  and  pressure  cycles  for  each  burn.  Since  the 
nozzle  expansion  ratio  is  a key  parameter  to  high  performance,  a compromise  between  atmosphere  and 
vacuum  is  required,  leading  to  a very  complex,  additional  set  of  environments  during  ground  start. 

Volumetric  and  weight  constraints  introduce  designs  which  create  additional  fluctuating  environ- 
ments. For  example,  curved  ducts,  bellows,  valves,  and  changing  duct/valve  diameter  create  higher 
velocities,  unsteady  flow  environments,  and  acoustic  pressures  which  are  additive  to  the  normal  turbine 
fluctuating  pressures  and  combustion  induced  noises. 

Combining  all  of  these  environments  leads  to  three  classical  design  problems,  (1)  strength  - 
pressures,  thermal  loads,  and  inertial  loads;  (2)  low  cycle  fatigue  - pressure  and  thermal  cycles 
associated  with  each  firing  that  is  unprecedented  in  rocket  engine  design,  and  (3)  high  cycle 
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FIGURE  1 . SSME  PROPELLANT  FLOW  SCHEMATIC 

fatigue/fracture  mechanics  - flow,  combustion,  and  mechanically  induced.  Strength  and  low  cycle 
fatigue  problems  have  been  solved  by  material  selection  and  design  considerations,  leading  to  an 
all-welded  design  using  exotic  materials.  The  other  major  challenge  was  high  cycle  fatigue  and 
fracture  mechanics.  The  SSME  operating  conditions  generate  environments  where  many  parts  are 
operating  at  or  beyond  their  endurance  limits,  producing  a limited  lifetime.  The  design  point  on 
the  SN  curve  is  very  flat,  making  lifetime  very  sensitive  to  small  changes  in  alternating  stresses 
(5%  alternating  stresses  change  lifetime  up  to  an  order  of  magnitude),  manufacturing  errors,  and 
material  deterioration  (see  Figure  2). 


FIGURE  2.  ALTERNATING  STRESS  VERSUS  LIFETIME 


387 


Taking  the  above-mentioned  considerations,  integrating  them  into  a structural  design,  manufactur- 
ing the  design,  and  final  verification  of  an  acceptable  product  results  in  a very  compelling  program. 
This  was  the  challenge  of  the  SSME  Program.  The  requirements  of  this  program  where  each  are  subsets 
of  the  challenge  are: 

1.  Develop  and  characterize  special  materials. 

2.  Develop  accurate  environment  predictions  and  verification  techniques. 

3.  Develop  accurate  structural  dynamic  and  stress  models  and  their  verification. 

4.  Develop  a fracture  mechanics  and  nondestructive  evaluation  (NDE)  program. 

5.  Develop  extensive  verification  procedures  (DVS). 

- Analysis. 

- Test. 

- Hot  firing  instrumentation. 

6.  Develop  accurate  and  technology-challenging  manufacturing  and  quality  control  procedures. 

Design  adequacy  is  assured  through  implementation  of  a Design  Verification  Specification  (DVS), 
which  is  a detailed  set  of  wel 1 -documented  tasks  with  government/industry  verification  with  complete 
signoff  on  each.  Tasks  are  broken  out  in  terms  of  engine  systems,  valves  and  ducts,  rotary  machinery, 
combustion  devices,  and  controller.  The  tasks  are  all  inconclusive  in  terms  of  analysis,  tests,  and 
hot  firing  verification.  Each  discipline  and  subsystem  maintains  current  documentation  of  all 
analyses  and  test  procedures  and  results  keyed  to  the  DVS.  In  addition  to  the  DVS,  many  system  re- 
quirements are  placed  on  total  engine  verification  accomplished  in  single  and  multi-engine  ground 
firings . 

The  approach  used  in  meeting  the  design  challenges  in  the  areas  of  strength,  low  cycle  fatigue, 
high  cycle  fatigue,  manufacturing,  and  material  processing  followed  classical  techniques.  Figure  3 
shows  this  approach  where  environments  are  predicted,  models  developed,  loads  calculated,  material 
properties  determined,  and  design  stresses  developed.  As  a result  of  tests,  component  firings, 
engine  developmental  firings,  and  DVS,  the  design  verification  cycle  becomes  one  of  iteration  where 
changes  in  each  discipline  are  made  as  additional  information  and  design  deficiencies  are  uncovered. 

As  a result  of  following  this  approach,  no  major  failure  has  occurred  during  SSME  developmental  firing 
for  parts  that  could  and  did  go  through  the  rigorous  7\  hours,  each  axis,  vibration  testing.  Failures 
have  occurred  but  only  in  those  areas  not  amenable  to  total  lifetime  testing  as  components. 
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The  major  challenge  that  faced  SSME  design  was  those  parts  which  were  sensitive  to  flow  environ- 
ments and  not  amenable  to  DVS  testing.  Analytical  procedures  were  not,  in  general,  accurate  enough  to 
predict  environments  and  the  engine  could  not  be  penetrated  in  all  areas  to  measure  the  environments 
(References  10-15). 

The  criticality  of  the  lifetime  of  certain  engine  components  and  the  complex  environment  predic- 
tion problem  have  led  to  an  alternate  approach  for  determining  high  cycle  fatigue  limits,  see  Figure  4. 
A component  failure  is  used  as  an  empirical  failure  reference  point,  determining  the  stress  level  re- 
quired for  failure  from  the  SN  curve  (minimum  properties,  maximum  predicted  temperature  and  pressures). 
The  environments  are  "backed  out"  of  these  empirically  derived  data  using  the  analytical  dynamic  model. 
The  environments  thus  derived  serve  as  a means  of  evaluating  new  designs  and  higher  engine  performance 
levels,  as  well  as  determining  life  limits. 

The  challenges  of  each  of  the  major  disciplines  will  be  discussed.  How  these  techniques  were 
applied  to  the  challenge  of  three  typical  design  problems  associated  with  lox  posts,  nozzle,  and 
turbine  blades  will  be  illustrated. 


(1)  EMPIRICALLY  UPDATED  MODEL  CAN  BE  USED  TO  PREDICT  REDESIGNED 
CONFIGURATION  CAPABILITY. 

(2)  THE  INPUT  ENVIRONMENTS  ARE  NOT  ACCURATELY  CHARACTERIZED 

(3)  RESULTS  ARE  WELL  ANCHORED  BUT  ARE  ONLY  RELATIVE  IN  TERMS  OF 
ANY  GIVEN  ELEMENT  DATA  BASE. 

(4)  ANALYSES  AND  TEST  ARE  BEING  USED  TO  UPDATE  AND  IMPROVE 
FIDELITY  OF  ENVIRONMENTS  (C) 


FIGURE  4.  SSME  LIFETIME  VERIFICATION  ANALYSIS  FOR  SPECIAL  PROBLEM  AREAS 

ENVIRONMENTS 


The  key  to  meeting  the  challenge  of  SSME  design  for  lifetime  prediction  and  verification  is  an 
accurate  determination  of  the  static  and  dynamic  environments.  As  discussed  previously,  in  the  high 
pressure  and  high  temperature  regimes  and  in  rotating  machinery,  large  mean  stresses  exist  which  drive 
the  accuracy  requirements  higher  for  both  static  and  dynamic  environments.  Classically,  these  environ- 
ments fall  into  the  categories  of  thermal,  mechanical,  flow,  and  acoustics. 


THERMAL  ENVIRONMENTS 

Definition  of  SSME  component  thermal  environment  is  required  to  determine  material  properties, 
structural  loads  due  to  thermal  gradients,  and  component  performance.  The  challenge  of  this  require- 
ment is  characterized  by  the  following: 


Temperature  extremes  from  -420°F  to  1800°F. 
Complex  fluid  flow  patterns. 

Intricate  geometrical  shapes. 
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• Exotic  superalloy  materials. 

• Transient  as  well  as  steady-state  phenomena. 

This  challenge  was  met  by  instrumentation  at  critical  locations,  analytical  extrapolation  of 
measured  temperatures,  and  calculation  of  temperatures  at  internal  locations  inaccessible  to  instru- 
mentation. In  many  cases,  post-test  hardware  inspection  revealed  evidence  that  resulted  in  additional 
instrumentation  and  revision  of  models  used  in  the  initial  characterization. 

Instrumentation  techniques  vary  from  externally  attached  thermocouples  and  "plug  in"  type 
resistance  thermometers  to  specially  assembled  "one  of  a kind"  instrumentation  systems  for  high  re- 
sponse, wide  range,  transient  measurements,  such  as  that  installed  to  assess  high  pressure  fuel 
turbopump  turbine  inlet  conditions.  Special  test  fixtures  and  experimental  models  representing 
engine  hardware  were  also  used  in  instances  where  instrumentation  of  actual  engine  operation  could 
not  be  effectively  accomplished.  This  was  necessary  for  thermal  assessment  of  shields  for  the  main 
injector  lox  posts.  In  addition,  limited  use  of  thermal  coatings,  temperature  sensitive  paints,  and 
even  metallurgical  evaluation  of  metal  discoloration  contributed  to  establishing  the  limits  of  SSME 
thermal  environments. 

Analytical  models  of  SSME  components  were  used  to  evaluate  temperatures  at  locations  other  than 
those  discretely  measured.  In  general,  thermal  models  must  interface  with  analyses  of  fluid  flow 
fields  to  achieve  boundary  conditions  and  with  structural  analysis  tools  for  meaningful  evaluation  of 
thermal  effects  on  SSME  capability  and  life.  Examples  of  computer  analysis  codes  employed  in  SSME 
thermal  analysis  are  SINDA,  NASTRAN,  BLAYER,  and  TSONIC. 

Analysis  results  are  evaluated  and  updated  by  comparison  to  periodic  inspection  of  actual  SSME 
hardware.  The  spectrum  of  models  utilized  ranges  from  one-dimensional,  constant  property,  steady- 
state  hand  calculations  of  average  material  temperatures  to  integrated  three-dimensional,  variable 
property,  transient  thermal /stress  analysis  of  fatigue  life. 

Frequently,  evaluation  of  test  anomalies  and/or  component  failures  requires  rapid  assessment  of 
component  temperatures  at  specified  locations.  These  analyses  are  performed  with  small  special-purpose 
computer  programs  or  hand  calculations.  Important  hypotheses  or  conclusions  reached  in  this  manner 
are  generally  verified  with  more  comprehensive  analysis  or  by  testing. 


MECHANICAL  VIBRATION  ENVIRONMENTS 

Mechanical  environments  are  design  drivers  for  many  components,  such  as  valves,  ducts,  and  bellows. 
The  sources  of  these  vibration  environments  are  rotating  machinery,  combustion,  shock,  valve  actuation, 
etc.  Figure  5 depicts  the  approach  for  working  these  environments.  Initial  design  values  were  scaled 
from  previous  engine  programs,  such  as  H-l  and  F-l . A comprehensive  hot  firing  measurement  program 
was  developed  for  updating  these  predicted  environments  during  the  developmental  firings.  Vibration 
criteria  have  been  gathered  and  put  in  statistical  form  for  all  major  components  at  each  power  level. 
These  data  were  statistically  evaluated  and  stored  in  data  banks. 


FIGURE  5.  SSME  VIBRATION  ENVIRONMENT  AND  COMPONENT  RESPONSE  PROCEDURE 


t 
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These  vibration  data  serve  as  the  criteria  for  vibration  testing  the  components  1\  hours  in  each 
axis.  This  is  a very  comprehensive  data  base  and  has  resulted  in  no  major  component  failure  of  any 
parts  that  have  passed  vibration  testing  (not  all  components  are  amenable  to  vibration  testing).  In 
many  cases,  this  testing  showed  design  flaws  that  were  corrected  with  the  components  subsequently 
passing  the  vibration  testing.  The  combination  of  hot  firing  data  acquisition  and  the  DVS  testing 
using  these  data  solved  the  challenge  associated  with  design  and  verification  against  vibration  environ- 
ments. 


FLOW  ENVIRONMENTS  (FLUCTUATING  PRESSURES) 

As  discussed  previously,  the  sensitivity  of  the  lifetime  of  SSME  parts  to  alternating  stresses 
places  a demanding  challenge  on  environment  predictions,  both  static  and  fluctuating.  The  sources  of 
these  fluctuating  pressures  are  blade  pass  from  rotating  machinery,  acoustical  resonances,  turbulent 
flow,  and  flow  instabilities.  The  challenge  was  met  using  previous  engine  test  data,  standard  flow 
data  from  flow  in  ducts  and  bellows,  etc.,  one-  and  two-dimensional  codes,  instrumentation  during 
engine  development  hot  firings,  and  special  component  flow  tests.  In  all  cases,  the  predicted  environ- 
ments were  anchored  using  hot  firing  data,  since  predictions  inherently  have  uncertainties  incompatible 
with  design  accuracy  requirements.  Limited  instrumentation  access  to  the  engine  flow  areas  has  re- 
stricted the  amount  of  hot  firing  data  that  could  be  acquired.  Data  have  been  acquired  in  the  hot  gas 
manifold  near  the  lox  post,  in  the  pump  discharge  areas,  and  in  certain  valves.  Development  of  special 
instrumentation  was  required  in  the  turbines  and  hot  gas  manifold.  Stringent  requirements  exist  for 
design,  development,  and  verification  of  this  instrumentation.  As  a result,  an  alternate  approach  was 
used  for  component  failure  cases  by  backing  the  environments  out  from  the  level  of  alternating  stresses 
required  to  produce  failure.  The  basic  requirements  for  defining  fluctuating  environments  have  been 
met  for  the  current  engine.  Challenges  still  exist  in  this  area  for  109%  power  level  verification  and 
upgrading  to  higher  power  levels.  In  the  examples  given  later,  some  of  these  approaches  will  be 
briefly  discussed. 


DYNAMICS 


Conventional  state-of-the-art  finite  element  structural  modeling  and  response  techniques  have  been 
used  for  the  SSME  to  predict  design  and  verification  data.  The  challenge  has  been  the  choice  of 
elements,  material  properties,  and  boundary  conditions  which  are  key  since  each  component  was  analyzed 
as  a unit.  Two-  and  three-dimensional  models  were  used  throughout  the  program.  Analysis  of  the  total 
engine  system  has  been  limited  since  local  conditions  drive  the  individual  component  design  with  small 
influences  from  system  dynamics.  The  basic  approach  has  been  to  1)  develop  finite  element  models  of 
each  component  or  subsystem;  2)  construct  generalized  force  distribution  of  the  environments:  flow, 

fluctuating  pressures,  thermal,  mechanical  vibrations;  3)  determine  resulting  loads  in  order  to  arrive 
at  design  loads  for  strength,  cyclic  loads  (low  and  high  cycle)  for  lifetime  predictions,  see  Figure  3. 

Analytical  models  have  been  anchored  using  special  dynamic  test  using  sine  sweep,  modal  dwell, 
and  random  testing  techniques.  Further  verification  has  been  obtained  from  developmental  firing  in- 
strumentation in  terms  of  strain  gauges  and  accelerometers.  Special  dynamic  tests  have  been  run  for 
total  engine  system,  powerhead,  lox  post,  nozzle,  main  fuel  and  oxidizer  valves,  and  high  pressure  lox 
and  fuel  pump  cases  and  rotors.  Dynamic  models  have  been  adequate  in  all  cases  to  define  dynamic 
responses. 


STRUCTURAL  ANALYSIS 


Stress,  fracture  mechanics,  and  strength  analyses  and  tests,  their  accuracy  and  efficiency,  and 
choice  of  design  criteria  are  key  elements  in  meeting  the  design  challenge  of  the  SSME  to  meet  the 
mission,  lifetime,  refurbishment,  and  operational  requirements.  Conventional  state-of-the-art  stress 
analysis  techniques  were  utilized  throughout  the  design  and  development  of  the  engine  components.  In 
the  preliminary  design  phase,  hand  analysis  solutions  and  selected  finite  element  models  were  utilized 
to  size  the  structure.  As  the  program  progressed  and  the  design  became  more  solidified,  the  majority 
of  the  critical  components  were  analyzed  through  the  use  of  either  two-dimensional  or  three-dimensional 
finite  element  models,  as  applicable.  In  many  cases,  common  models  were  used  for  both  the  dynamic  and 
stress  analyses,  and,  in  some  instances  such  as  the  turbine  blades,  the  same  model  was  used  for  de- 
tailed dynamic,  thermal,  and  stress  analyses.  The  finite  element  models  included  both  elastic  and 
plastic  solutions  as  required.  The  design  margins  or  factor  of  safety  requirements  utilized  in  the 
engine  design  were: 

t Factor  of  safety  on  ultimate  = 1.50  pressure  only, 
t Factor  of  safety  on  ultimate  = 1.40  combined  loads. 
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t Factor  of  safety  on  yield  = 1.10. 

9 Factor  of  safety  on  low  cycle  fatigue  =4.0. 

• Factor  of  safety  on  high  cycle  fatigue  = 4.0  or  10.0,  depending  on  adequacy  of  SN  curve  data  base. 

• Factor  of  safety  on  creep  = 10.0. 

The  overall  design  goal  was  infinite  life  with  at  least  a factor  of  1.0  on  the  endurance  limit, 
except  for  the  rotating  components  in  the  turbomachinery  where  the  factor  of  safety  of  1.4  was  used. 

When  other  design  constraints  prohibited  meeting  this  design  goal,  the  safety  factors  on  life  were 
utilized.  Miner's  rule  for  accumulated  damage  was  generally  used  for  assessing  components  subject  to 
the  combined  effects  of  low  cycle,  high  cycle,  and  creep  damage.  The  majority  of  the  engine  components 
subjected  to  high  cycle  fatigue  environments  operate  on  the  flat  or  close  to  the  flat  portion  of  the 

SN  curve  due  to  the  combination  of  the  27,000-second  life  requirement  and  the  operating  frequency  of 

the  component,  see  Figure  2.  This  contributed  to  several  high  cycle  fatigue  failures  during  the  re- 
search and  development  phase  of  the  program,  for  example,  the  main  injector  lox  post,  which  experienced 
several  failures.  In  retrospect,  it  could  be  questioned  whether  it  would  have  been  prudent  to  design 
all  life  sensitive  components  to  a higher  factor  against  the  endurance  limit,  such  as  1.25,  rather  than 
1.0.  The  larger  factor  would  result  in  tradeoffs  between  weight,  reliability,  development  costs,  and 
performance. 

The  early  design  phase  was  further  complicated  by  the  lack  of  complete  characterization  of  material 
properties  for  all  of  the  extreme  temperatures  and  environments.  Much  of  the  early  analyses  had  to  be 
accomplished  with  estimated  properties  until  adequate  characterization  could  be  completed  when  all 
environments  were  finalized  and  schedule  and  cost  permitted. 

The  structural  reliability  (ultimate  load  and  life  capability)  was  verified  by  such  methods  as  hot 
firing  developmental  and  certification  testing,  component  static  structural  tests,  proof  tests,  and 
laboratory  vibration  tests.  These  tests  were  utilized  to  verify  the  structural  reliability  of  the 
critical  components.  Appropriate  instrumentation,  pressures,  temperatures,  environments,  loads,  cycles, 
etc.,  were  utilized  where  applicable  and  practical  for  this  accomplishment. 


FRACTURE  MECHANICS  ANALYSES 

The  objective  of  the  fracture  mechanics  analyses  was  to  assess  the  flight  engines  fracture 
critical  components  for  fl ightworthiness  based  on  fracture  mechanics  logic  and  nondestructive  in- 
spection history.  Fracture  critical  components  were  selected  using  the  following  guidelines: 

1.  Components  made  of  Inconel  718  and  whose  operating  conditions  involve  exposure  to  gaseous 
hydrogen  temperatures  which  are  determined  to  result  in  accelerated  flaw  rates. 

2.  All  shrapnel -producing  hardware  such  as  turbine  disks,  pump  inducers,  or  impellers. 

3.  Major  structural  elements  loaded  in  tension  or  bending. 

4.  All  turbopump  housings. 

Engineering  judgment  was  applied  with  consideration  of  component  function,  failure  effects,  de- 
sign complexity,  and  known  material  characteristics.  The  above  selection  logic  resulted  in  approxi- 
mately 300  fracture  critical  locations  involving  approximately  60  components  on  the  engine.  Figure  6 
is  a flow  diagram  of  the  fracture  mechanics  verification  analysis  procedure. 

The  application  of  fracture  mechanics  for  the  engine  components  was  based  on  the  following 
simple  logic: 

1.  Determine  the  maximum  size  of  any  undetected  flaw  that  may  be  present  in  the  subject 
structure  at  the  time  it  enters  service. 

2.  Based  on  the  results  of  1 . , calculate  the  number  of  service  loadings  that  will  cause  the 
undetected  flaw  to  grow  to  critical  size,  thereby  precipitating  failure. 

3.  Compare  the  predicted  number  of  service  loading  cycles  before  failure  with  the  design  require- 
ments. 

The  information  necessary  to  perform  step  1.  may  be  obtained  from  either  proof  testing  or  the 
inspection  procedure  used  to  detect  flaws.  When  proof  testing  is  used  to  determine  the  maximum 
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undetected  flaw  size,  the  analysis  is  called  proof  test  logic.  The  stresses  imposed  during  proof  test- 
ing are  related  to  the  material  fracture  properties  through  fracture  mechanics  formulas  which  predict 
the  maximum  undetected  flaw  that  would  not  precipitate  proof  test  failure.  When  proof  testing  does 
not  provide  adequate  structural  assurance,  NDE  is  used  and  based  on  the  undetectable  flaw  size. 

The  preferred  method  for  determining  the  maximum  undetected  flaw  is  the  proof  test  logic  approach, 
but  due  to  the  characteristics  of  the  materials  (tough  ductile  materials  that  exhibit  stable  flaw 
growth),  this  approach  was  only  applicable  to  a few  aluminum  components.  The  NDE  approach  was, 
therefore,  utilized  extensively  through  the  engine,  both  on  the  fracture  critical  and  nonfracture 
critical  components.  It  was  the  general  policy  to  proof  test  all  pressurized  hardware,  where  feasible 
and  practical,  to  a proof  factor  of  1.20  times  limit  design  operating  pressure,  for  5.0  cycles  to 
assure  good  quality  hardware  and  a measure  of  structural  integrity. 

A program  has  been  baselined  which  subjects  high  time  hardware  to  teardown  inspections  periodi- 
cally throughout  the  program  to  verify  the  fracture  mechanics/NDE  logic  approach.  As  a result  of 
these  inspections,  adjustments  will  be  made  to  the  procedure  as  required. 
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FIGURE  6.  VERIFICATION  ANALYSIS  PROCEDURE 


MATERIALS 


The  combination  of  design  envelope  requirements , complex  service  environments,  and  severe  load 
conditions  described  in  the  preceding  sections  led  to  material  performance  criteria  that  were  differ- 
ent from  those  normally  encountered  in  high  performance  engine  systems.  Resistance  to  time-dependent, 
steady-state  load  conditions  ( i . e . , creep  and  stress-rupture  strength)  were  of  minor  importance  due 
to  the  short  operating  lifetime  of  the  SSME.  Classical  stress  corrosion,  while  a consideration  in 
material  selection,  was  not  encountered  during  the  test  and  operational  phases.  Even  the  traditional 
material  design  allowables,  ultimate  and  yield  strength,  within  obvious  limits  would  be  viewed  as 
having  a relatively  minor  impact  on  the  SSME  design.  Material  considerations  of  major  importance 
included  high  cycle  fatigue  (HCF),  low  cycle  fatigue  (LCF),  and  hydrogen  environment  embrittlement 
(HEE).  Fracture  mechanics/flaw  growth  characteristics  had  to  be  determined  under  conditions  of  HCF, 
LCF,  and  HEE  (References  16  and  17).  Finally,  there  was  the  extremely  critical  ability  of  the 
material  to  be  "forgiving"  with  respect  to  unusual  or  unplanned  manufacturing  practices;  this 
property  will  be  loosely  referred  to  as  "fabricabil ity"  in  the  following  discussion. 
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HIGH  CYCLE  FATIGUE 


Although  the  life  of  the  SSME  is  short  in  terms  of  operating  time,  high  frequency  vibrations 
and  pressure  fluctuations  drive  many  of  the  structural  components  into  the  HCF-critical  regime.  A 
major  deficiency  existed  in  the  HCF  data  base,  due  to  the  need  for  special-purpose  materials  that 
were  not  characterized  in  existing  material  properties  manuals.  This  was  compounded  by  operating 
conditions  and  temperatures  which  had  major  effects  on  HCF  properties,  often  making  it  necessary  to 
generate  additional  HCF  properties  for  materials  that  were  covered  in  the  design  literature.  Syner- 
gistic effects  of  residual  stress  from  transient  loads  and  the  relaxation  of  residuals  during 
mainstage  operations  could  only  be  measured  in  the  laboratory.  The  effectiveness  of  standard  HCF 
control  procedures,  such  as  shotpeening  and  stress  relief,  had  to  be  confirmed  under  the  operating 
environments  of  the  SSME.  The  result  was  a long  and  continuing  process,  as  follows: 

1.  Define  the  operating  conditions. 

2.  Develop  design  criteria  using  available  data  and  (conservative)  rules  for  lower-bounding 
HCF  behavior. 

3.  Fill  the  required  need  for  additional  data  in  the  laboratory. 

4.  Check  the  validity  of  the  assumptions  made  in  2. 

The  process  is  continuing,  e.g.,  the  turbine  blade  material,  directionally-solidified  MAR-M-246(Hf ) , 
has  been  evaluated  for  at  least  eight  operating  temperatures,  five  stress  ratios  ("R"),  six  test 
frequencies,  and  under  numerous  empirical  conditions  simulating  turbine  operating  conditions. 

Figure  7 shows  some  of  the  data,  addressing  the  question  of  test  frequency  effects.  The  evaluation 
of  the  HCF  behavior  of  the  turbine  blade  material  is  still  in  progress. 


A 6.3  KHz 
O 10  KHz 
□ 14.2  KHz 
* 20.8  KHz 


105  10®  107  10®  109 

CYCLES  TO  FAILURE  NF 

FIGURE  7.  HIGH  CYCLE  FATIGUE  DATA  FOR  MAR-M-246(Hf ) DIRECTIONALLY  SOLIDIFIED 
TURBINE  BLADE  MATERIAL,  GENERATED  AT  ULTA-HIGH  FREQUENCIES 


LOW  CYCLE  FATIGUE 

Many  areas  in  the  SSME  experience  LCF  conditions,  loosely  defined  here  as  cyclic  strain  in  the 
inelastic  range.  LCF  level  strains  occur  during  transient  startup  and  shutdown  conditions,  or  as  a 
result  of  thermal  deformations  during  mainstage.  Generally,  one  or  two  LCF  cycles  are  applied  per 
operating  cycle,  but  the  strain  levels  are  very  high,  well  in  excess  of  the  engineering  yield  strain. 
LCF  data  were  obtained  for  all  of  the  structural  materials  on  the  SSME  and  were  used  to  develop  design 
modifications  to  ensure  adequate  LCF  life.  This  process  is  continuing;  many  SSME  components  are  LCF- 
life  limited. 
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HYDROGEN  ENVIRONMENT  EMBRITTLEMENT 


Not  to  be  confused  with  classical  hydrogen  embrittlement,  HEE  refers  to  the  real-time  effect  of 
hydrogen  on  ductility  and  strength.  It  is  generally  limited  to  certain  alloy  systems  operating  in  the 
inelastic  strain  range,  but  one  of  the  affected  material  systems  is  the  nickel-based  alloys,  which 
include  the  major  structural  material  in  the  SSME,  Inconel  718.  HEE  does  not  usually  occur  at  cryo- 
genic or  elevated  temperatures;  it  is  only  a design  consideration  at  temperatures  that  would  otherwise 
be  considered  benign,  close  to  room  temperature.  A thin  layer  of  nonsusceptible  material  is  an 
adequate  shield  against  HEE,  hence  control  measures  frequently  include  electroplating  of  copper,  gold, 
and  other  materials.  In  cases  where  the  area  in  contact  with  gaseous  hydrogen  is  the  underside  of  a 
closeout  weld  and  is  inaccessible  for  plating,  welding  techniques  have  been  developed  and  characterized 
which  involve  an  underlay  and  root  pass  made  from  a nonsusceptible  material,  see  Figure  8.  When 
possible,  design  modifications  have  been  made  to  eliminate  the  conditions  that  cause  HEE,  such  as 
stress  concentrations  (e.g.,  inelastic  strains).  Non-traditional  concepts  of  materials  usage  have 
emerged  in  the  control  of  HEE.  For  example,  one  common  procedure  involves  modifying  the  operating 
temperature  to  move  it  out  of  the  HEE  range. 


FIGURE  8.  SPECIAL  WELD  UNDERLAY  CONFIGURATION  FOR  CLOSEOUT  WELDS  IN  HYDROGEN  SYSTEMS 


FABRICABILITY 

Building  an  SSME  is  a sequential  operation  involving  expensive,  long  lead  items,  usually  joined 
by  welding.  Manufacturing  discrepancies  are  inevitable,  and  it  would  not  be  feasible  to  scrap  an 
assembly  each  time  a major  discrepancy  occurred.  Perhaps  more  than  any  other  characteristic, 
"forgiveness"  with  respect  to  repairs  and  unconventional  processing  is  a major  consideration  in 
material  selection.  For  example,  despite  being  susceptible  to  damage  from  a hydrogen  environment, 
as  noted  above,  Inconel  718  is  the  major  structural  material  of  the  SSME.  Laboratory  tests  have  shown 
that  the  weld  tensile  and  HCF  properties  are  unaffected  after  as  many  as  sixteen  repairs  in  the  same 
location.  Solutionizing  and  aging  times  and  temperatures  can  be  varied  over  a wide  range,  with 
little  effect  on  mechanical  properties,  so  that  furnace  brazing  and  heat  treatment  can  be  accomplished 
in  one  operation.  Undercuts  due  to  mismatching  are  routinely  filled  in  by  welding  and  fairing,  and 
the  part  is  restored  to  design  material  requirements  by  heat  treatment.  Inconel  718  can  be  struc- 
turally welded  to  a large  number  of  dissimilar  materials  by  a number  of  welding  processes,  using  many 
different  filler  materials.  All  of  the  preceding  fabricabil ity-related  characteristics  have  been 
evaluated  in  the  laboratory,  and  the  resulting  material  design  allowables  have  been  documented. 
Additional  requirements  will  develop  as  the  SSME  design  continues  to  evolve  in  the  direction  of  in- 
creased performance. 


TYPICAL  EXAMPLES 


Typically,  SSME  lifetime  problems  have  been  characterized  and  solved  in  a unique  manner.  The 
large  sensitivity  of  lifetime  to  small  changes  in  alternating  stress,  temperatures , etc.,  moves  beyond 
fluid  flow  analysis  accuracy  capability  dictating  that  lifetime  be  determined  from  hot  firing  data  in 
conjunction  with  analysis  (Reference  10).  The  approach  was  discussed  previously,  see  Figure  4.  Using 
this  approach  in  conjunction  with  the  LRU  concept  has  produced  an  acceptable  solution  to  the  challenge. 
Examples  are  now  given  of  how  the  challenge  was  met. 
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LOX  POSTS 


The  main  injector  is  part  of  the  hot  gas  section,  which  is  the  heart  of  the  SSME.  It  includes  a 
hot  gas  manifold,  primary  and  secondary  face  plates,  a lox  dome,  and  600  lox  posts  or  feed  tubes  be- 
tween the  lox  dome  and  the  primary  injector  plate.  Figure  9 shows  a top  plane  view  of  the  lox  post 
array  with  the  three  transfer  tubes  from  the  hydrogen  preburner  and  the  two  transfer  tubes  from  the 
lox  preburner. 


Pi 


FIGURE  9.  TOP  PLANE  VIEW  OF  LOX  POST  ARRAY 


High  velocity  gas  at  a temperature  of  approximately  1800°F  flows  through  the  injector,  then 
through  the  gap  at  the  base  of  each  post  and  around  the  tip  of  the  injector  plate,  where  it  mixes  with 
the  liquid  oxygen  flowing  down  the  center  of  the  post.  This  flew  environment,  coupled  with  mechanical 
vibrations  and  variable  dynamic  characteristics,  produces  severe  high  cycle  fatigue  loading  on  the  lox 
posts.  This  is  augmented  by  high  static  stresses  resulting  from  the  thermal  and  static  pressure  loads. 
Flow  shields  (see  Figure  10)  have  been  added  to  the  outermost  row,  but  the  posts  are  still  high  cycle 
fatigue  life  limited,  and  there  have  been  two  related  engine  failures  during  demonstration  firings. 
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Metal! urgial  analysis  determined  that  the  failure  mechanism  was  high  cycle  fatigue,  initiating 

in  the  threads  of  the  face  plate  retainer.  Sources  of  alternating  stress  at  that  point  are  mechanical 

oscillations,  vortex  shedding,  and  fluctuating  pressures  (flow  and  acoustics).  Static  loads  arising 
from  thermal  gradients  and  internal  flow  induced  pressures  are  superimposed  as  a nigh  mean  stress  to 
the  alternating  loads.  Despite  the  presence  of  the  flow  shields,  the  highest  fatigue  loads  and  most 
frequent  occurrence  of  fatigue  cracks  are  in  the  outermost  posts,  row  13. 

The  approach  used  to  rationalize  the  hypothesized  failure  mode  was  the  approach  shown  on 
Figure  4.  Certain  aspects  of  the  problem  can  be  handled  analytically  with  good  success.  For  instance, 
the  analysis  has  shown  a mechanical  and  fluctuating  pressure  environment  in  the  1200  Hz  regime,  which 
couples  with  and  drives  the  modes  (natural  frequencies)  of  the  posts;  these  analytical  modes  have  been 
verified  experimentally  and  by  instrumented  lox  posts  in  hot  firings.  Cold  flow  tests  of  the  hot  gas 
manifold,  powerhead,  and  lox  post  were  used  as  a test  bed  for  flow  characteristics. 

Demonstrated  lifetimes  from  single  engine  firings  have  been  combined  with  analytical  data  to 

arrive  at  lifetime  predictions.  Figure  2 is  a plot  of  alternating  stress  capability  versus  number  of 

cycles,  taking  into  account  static  loads  and  temperature  effects.  Two  empirical  data  points  have  been 
assumed:  1)  a 750-second  failure  time  for  a single  post,  as  observed  in  one  engine  test,  and  2)  the 

5,000-second  cracked  post  case  demonstrated  for  shielded  posts.  The  first  bar  is  the  alternating 
stress  for  the  single  post  mode  (750  seconds)  showing  the  combined  stress  induced  by  mechanical  and 
fluctuating  pressure.  The  analysis  was  adjusted  to  predict  high  cycle  fatigue  failure  in  750  seconds 
using  mechanical  and  fluctuating  pressure  forcing  function  ranges  based  on  best  estimates  from  hot 
firing  measurements.  The  second  bar  is  the  two-post  flow  shield  predicted  alternating  stresses  for 
mechanically  and  flow-induced  oscillations  using  a model  adjusted  in  the  same  manner  (Reference  10). 

The  model  has  been  used  to  redesign  the  posts  to  assure  long  life  and  to  increase  engine  performance 
from  shield  removal.  The  redesign  involves  a two-phased  approach.  Phase  1 is  a change  of  material 
from  ORES  316L  to  Haynes  188S  (used  in  FPL  engine  configuration),  raising  the  alternating  stress 
allowable  by  approximately  a factor  of  two.  The  second  phase  is  a heavier  post,  which  will  further 
increase  the  alternating  load  capability. 


TURBINE  BLADES 

The  high  pressure  fuel  turbopump  (HPFTP)  is  a three-stage  centrifugal  pump  that  is  directly 
driven  by  a two-stage  hot-gas  turbine.  The  turbine  is  powered  by  hot  gas  (hydrogen  rich  steam) 
generated  by  the  fuel  preburner.  Hot  gas  enters  the  turbine  and  flows  across  the  shielded  support 
struts,  through  the  first  and  second  stage  nozzles  and  blades,  and  is  discharged  into  the  hot  gas 
manifold.  Requirements  for  high  performance  within  a restricted  envelope  have  led  to  a complex, 
cyclic-load-producing  configuration  of  13  struts,  41  first  stage  nozzle  vanes,  and  59  second  stage 
turbine  blades.  There  have  been  numerous  instances  of  cracking  in  both  the  first  and  second  stage 
turbine  blades  at  the  locations  shown  in  Figure  11.  Although  none  has  precipitated  an  engine 
failure,  turbine  blade  life  improvement  remains  a major  goal  in  the  SSME  Program. 

Loads  analysis  and  lifetime  prediction  for  the  HPFTP  turbine  blades  have  presented  problems 
similar  to  those  encountered  in  the  lox  posts.  Major  problems  have  included  environment  definition, 
dynamic  modeling,  and  static  and  alternating  stress  distribution.  The  environment  definition  is 
extremely  complex  for  both  the  thermal  and  fluctuating  pressure  standpoints.  The  blades  are  near  the 
preburner  and  use  the  hot  preburner  gas  as  the  source  of  their  power  (flow  forces).  These  environ- 
ments are  not  uniform  due  to  baffle  posts,  struts,  etc.,  and  the  blade  geometry.  Fluctuating 
pressures  present  the  same  problem,  plus  the  clear  introduction  of  harmonics  due  to  the  struts  and 
the  multi  blade  passages.  Dynamic  modeling  is  complicated  by  the  basic  geometry,  hot  surface, 
boundary  conditions  at  the  wheel,  and  special  dampers  for  reducing  blade  response.  Stress  is  composed 
of  static  centrifugal  force,  power  bending,  steady-state  thermal,  cyclic  thermal  (start  and  shutdown 
transients),  and  fluctuating  pressure  components.  Significant  factors  in  the  alternating  stress  are 
1)  tuning  of  strut  wakes  with  blade  lower  modes,  2)  multiblade  relative  motion  of  adjacent  blades, 

3)  variable  damping  coefficients  and  lockup,  4)  changes  through  engine  operating  range,  and  5)  startup 
and  shutdown  thermal  and  pressure  cycles. 

Each  instance  of  blade  cracking  has  been  addressed  using  an  analytical /empirical  approach  similar 
to  that  described  for  the  lox  posts;  loads  and  stresses  are  calculated  by  analysis,  and  the  models  are 
adjusted  as  required  to  be  compatible  with  observed  phenomena.  A detailed  finite  element  model  has 
been  generated  for  the  blades.  Detailed  definition  of  the  forcing  functions  has  been  accomplished 
by  accurate  modeling  of  the  strut/nozzle/blade  configuration,  and  the  output  has  been  matched  to 
results  obtained  from  special  air  rig  and  "whirlygig"  tests.  Basic  material  strength  and  fatigue 
data  have  been  obtained  over  a range  of  operating  stresses  and  temperatures.  Figure  12  shows  the 
form  of  the  engineering  solution  with  all  of  the  data  taken  into  consideration,  including  the  observed 
frequency  of  the  particular  blade  cracking  incident  under  investigation.  Curve  1 is  for  rated  engine 
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power  level  (RPL)  assuming  5,000  seconds  of  life.  Curve  2 is  full  or  maximum  engine  power  level  (FPL) 
and  5,000  seconds  of  life,  while  curve  3 is  the  same  power  level  assuming  2,500  seconds  of  life.  The 
mean  stress  for  RPL  is  46  Ksi,  and  for  FPL,  it  is  55  Ksi.  The  blade  operating  temperature  is  in  the 
1,600  to  1,700  degree  range,  resulting  in  a low  allowable  alternating  stress. 

At  the  present  time,  there  are  no  serious  blade  cracking  problems.  Each  instance  of  blade 
cracking  has  been  solved  by  material -related  improvements  or  environment  modifications.  Periodic 
inspections  are  required,  however,  and  the  average  blade  changeout  interval  of  3,000-5,000  seconds 
is  far  short  of  the  design  goal  of  27,000  seconds.  Studies  for  long-term  improvement  in  blade  life 
are  in  progress.  Improved  materials  are  being  considered,  including  advanced  superalloys  in  the 
single  crystal  form,  and  environment  reduction  techniques  are  under  study. 


FIGURE  11.  AREAS  OF  HIGH  STRESS  AND  OBSERVED  CRACK  FORMATION 
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NOZZLE  AND  STEERHORN  ENGINE  SIDE  LOADS 


The  SSME  nozzle  has  three  engine  downcomer  coolant  lines  that  take  hydrogen  from  the  main  fuel 
valve  to  the  aft  nozzle  manifold.  The  aft  nozzle  manifold  feeds  the  coolant  tubes  which  in  essence 
is  the  engine  nozzle.  Two  of  these  coolant  lines  have  failed  during  hot  engine  firings  due  to  high 
cycle  fatigue.  Figure  13  gives  the  basic  configuration,  showing  the  downcomer  line  (steerhorn).  A 
history  of  cracking  nozzle  tubes  has  also  plagued  the  engine. 


STEERHORN 


The  loads  on  the  line  nozzle  system  arise  from  firing  of  a high-expansion-ratio  nozzle  under 
ground  atmospheric  conditions.  The  plume  does  not  fill  the  nozzle  until  the  internal  pressure  is 
greater  than  atmospheric  pressure.  As  the  nozzle  plume  flow  velocity  increases,  it  passes  through 
a region  where  a Mach  disc  or  cone  exits  the  nozzle.  Two  distinct  phenomena  occur  during  this  thrust 
buildup  phase.  The  first  occurs  around  600  to  700  psia  chamber  pressure.  In  this  case,  the  plume  is 
basically  cylindrical  in  nature  and  is  directionally  unstable,  moving  around  radially  within  the 
nozzle.  The  loads  induced  by  this  case  drive  the  actuator  design.  The  second  occurs  around  1,200  psia 
where  the  Mach  cone  leaves  or  enters  the  nozzle,  creating  high  local  shock  loads.  Figure  14  shows  a 
typical  thrust  buildup  and  shutdown  curve  and  stress  response  measured  on  the  nozzle  steerhorn.  The 
side  loads  response  is  clearly  shown  in  this  figure.  The  large  strain  amplitude  occurs  due  to  the 
excitation  of  the  n = 0 (expansion  mode)  and  the  n = 6 (shell  mode).  Notice  that  the  response  is  very 
sharp  and  around  250  Hz  (the  insert  shows  a blowup  of  the  response)  (References  10,  13,  14,  15,  and 
18). 


Figure  15  depicts  the  n = 6 shell  mode  on  the  right-hand  side.  The  left-hand  side  of  the  figure 
shows  the  shell  mode  frequencies  as  a function  on  n-number.  At  the  bottom  of  the  figure  is  a spectrum 
of  the  measured  acceleration  of  the  engine  nozzle  aft  manifold  showing  presence  of  all  n modes  but 
by  far  the  larger  peak  occurring  for  the  n = 0 and  n = 6 modes. 

The  presence  of  this  large  load  at  the  discrete  frequency  of  250  Hz  (near  resonance  with  nozzle 
modes)  created  many  engine  design  and  program  problems,  particularly  during  the  developmental  firing 
program.  Two  things  had  to  be  accomplished.  The  underdesigned  steerhorn  had  to  be  fixed  so  that 
firings  could  continue,  and  the  steerhorn  had  to  be  redesigned  for  operational  flights.  Since 
initially  an  internal  nozzle  pressure  forcing  function  was  not  available,  it  was  decided  to  take  the 
hot-firing  measured  accelerations  at  the  aft  manifold  and  use  these  to  base  drive  a dynamic  model  of 
the  steerhorn.  The  first  major  result  obtained  was  that  just  thickening  the  tube  helped  the  problem. 
The  increased  mass  offsets  the  increased  stiffness  so  the  frequency  stays  the  same.  The  nozzle- 
induced  driving  force  is  not  changed;  therefore,  the  increased  mass  increases  the  steerhorn  loads 
proportionally  to  the  mass  increase.  As  a result,  a sensitivity  analysis  and  redesign  matrix  was 
pursued  as  a means  of  obtaining  a solution. 

The  conclusion  of  this  study  was  that  the  horizontal  run  of  the  steerhorn  must  be  fixed  to  the 
nozzle  stiffness  ring  to  reduce  loads.  This  meant  that  a steam  loop  had  to  be  incorporated  above  the 
hatband  to  take  out  thermal  induced  expansion  loads.  The  other  main  result  was  that  for  the  T area 
(original  design)  a nickel-plating  would  provide  adequate  life  for  developmental  engine  firings  and 
first  Shuttle  flights.  The  redesigned  steerhorn  was  incorporated  on  the  FPL  engines. 
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ENGINE  0007,  TEST  901-250 


FIGURE  14.  STEERHORN  STRAINS  IN  TRANSIENT  OPERATION 


NOZZLE  SHELL  MODE 

DEFINED  BY  ROCKETDYNE  MODAL  SURVEY  TEST 


THIS  RADIAL  MODE  EXCITED  BY  EITHER  RADIAL 
OR  AXIAL  EXCITATION  FORCES. 


+1.152E  ♦ 003 


234  1150.44  Q 

259  335.55 

352  143.84 

342  136.82 


MEASURED  RADIAL  ACCELERATION  OF  MANIFOLD  AT  T LOCATION 
TEST  6003  ME— 3 AF  MN-YSL  RAD  S ♦ 9.4  100% 


FIGURE  15.  NOZZLE  SHELL  MODE  DEFINED  BY  ROCKETDYNE  MODAL  SURVEY  TEST 
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Two  test  programs  were  instituted  to  finalize  these  loads  and  the  redesign:  Scale  model  engine 

cold-flow  test  and  full-scale  flight  nozzle  dynamic  test.  The  dynamic  model  used  in  this  analysis 
was  verified  in  a full-scale  dynamic  test.  Analytical  modes  had  good  agreement  with  test  modes.  The 
cold-flow  model  test  varied  the  flow  rate,  etc.,  and  determined  the  forcing  functions.  A full  set  of 
pressure  gauges  was  mounted  so  that  the  force  distribution  could  be  determined.  These  results  were 
scaled  to  full  scale. 

Using  these  test-derived  forcing  functions,  a dynamic  response  analysis  was  made  for  both  the 
original  design  and  the  redesigned  steerhorn  configurations  (steam  loop).  Good  agreement  with  hot- 
firing  data  was  obtained.  The  reduction  in  loads  is  approximately  40  percent  for  the  redesigned 
case,  providing  infinite  life.  Table  1 is  a summary  of  stresses  measured  in  hot-firing  data  for  the 
nonsteam  loop  configuration. 


DATA  BASE 


COMBINED  ALL  STANDS 
ALL  MEASUREMENTS 
ALL  EVENTS 
41  TESTS 


TABLE  1.  HOT-FIRING  DATA  SUMMARY 

STRAIN  AT  T LOG  DISTRIBUTION* 


START 


19,053 


CUTOFF 


STAND 

MEAN 

30; 

MEAN 

3<7 

A1 

(14  TESTS) 

3,262 

10,537 

5,033 

15,642 

A2 

(20  TESTS) 

3,876 

16,503 

1 ,636 

6,529 

MPT 

(3  TESTS,  7 ENGINES) 
MPT  & A1 

6,270 

20,685 

4,916 

12,088 

4,064 

18,469 

4,938 

13,552 

COMBINED  ALL  STANDS 
(41  TESTS) 

3,954 

17,084 

2,722 

21 ,528 

♦CONTAINS  NO  EXTRAPOLATED  DATA. 


Test  stand  A-2,  which  has  a simulation  for  altitude  (reduced  pressure),  showed  different  charac- 
teristics from  the  other  stands.  Based  on  this  analytical  work  and  the  statistics  of  the  hot-firing 
data,  a lifetime  prediction  of  the  redesigned  steerhorn  was  accomplished  verifying  a redesign  that 
would  meet  the  55-mission  lifetime  requirement. 


CONCLUSIONS 


The  design,  manufacturing,  and  verification  of  the  SSME  has  been  one  of  the  major  challenges  in 
obtaining  an  operational  Space  Shuttle.  Basic  problems  have  been  met  with  a high  performance  engine 
and  acceptable  refurbishment  requirements.  Additional  efforts  are  required  for  efficient  refurbish- 
ment regimes  and  to  have  the  potential  for  higher  performance  to  meet  future  Shuttle  mission 
requirements. 

The  first  six  Shuttle  flights  had  engine  performance  as  predicted  with  no  failures.  Using  the 
LRU  concept,  some  pumps  were  changed  out  as  planned.  The  engine  system  has  met  the  basic  design 
challenges. 
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(SHUTTLE  TILE  STRUCTURAL  INTEGRITY) 


William  C.  Schneider  and  Glenn  J.  Miller 
NASA  Lyndon  B.  Johnson  Space  Center 
Houston,  Texas  77058 


INTRODUCTION 


The  launch  and  landing  of  the  U.S.  Space  Shuttle  Orbiter  has  now  become  almost  routine.  The  de- 
velopment of  such  a highly  successful  vehicle  involved  the  resolution  of  many  challenging  problems. 
One  problem  area  where  the  challenges  to  creativity,  inventive  design,  and  analytical  understanding 
were  particularly  demanding  involved  the  structural  integrity  of  the  thermal  protection  system  (TPS). 
The  problems  associated  with  these  tiles  were  resolved  in  the  unfavorable  engineering  environments  of 
tight  schedule,  budget  constraints,  and  high  public  visibility.  The  successful  resolution  of  these 
problems  is  evident  with  each  landing  of  the  Shuttle  (fig.  1). 


The  Orbiter  is  essentially  a conventional  skin  stringer  aluminum  structure  with  some  limited 
usage  of  graphite  epoxy  for  the  cargo  bay  doors  and  orbital  maneuvering  system  (OMS)  pods.  The 
properties  for  these  materials  dictate  a maximum  structural  temperature  of  350°  F.  The  reusability 
goal  of  100  missions  necessitates  a lightweight  nonablative  TPS  that  protects  the  structure  and 
withstands  the  thermal  and  environmental  loads  of  space  flight.  The  TPS  material  selected  (LI900) 
was  developed  by  Lockheed  Missiles  and  Space  Company  and  is  an  exceptional  thermal  insulator.  This 
ceramic  material  is  highly  brittle  and  has  a low  coefficient  of  thermal  expansion.  Therefore,  any 
contraction  of  the  aluminum  skin  to  which  the  tiles  are  directly  bonded  would  cause  the  reusable  sur- 
face insulation  (RSI)  to  fracture.  To  minimize  in-plane  incompatibility,  a felt  strain/isolator  pad 
(SIP)  was  bonded  between  the  tiles  and  the  structure  (fig.  2). 

In  addition,  the  plan  form  dimensions  for  most  lower  surface  tiles  were  on  the  order  of  6 inches 
or  less.  The  6-inch  dimension  was  computed  so  as  to  meet  the  requirement  that  the  tile  gaps  should 
be  no  less  than  0.010  inch.  This  occurs  during  entry  (when  the  structure  is  still  cold  from  deep- 
space  radiation)  as  the  tiles  become  hot.  The  stiffness  and  dimensions  of  the  SIP  were  designed  to 
minimize  the  stresses  induced  into  the  brittle  tile  material  from  deformations  predicted  for  the  alu- 
minum structure.  Initially,  the  stresses  expected  in  the  TPS  were  well  within  the  strength  of  the 
RSI,  but  as  the  design  of  the  Orbiter  progressed,  mission  requirements  became  firmer,  and  load  predic- 
tions became  refined,  it  became  clear  that  the  TPS  would  have  to  withstand  loads  higher  than  origi- 
nally anticipated.  Additionally,  stress  concentrating  stiff  spots  were  found  to  exist  in  the  SIP 
(fig.  3).  These  stiff  spots  (caused  by  needling)  decreased  the  allowable  system  strength  to  6 psi  in- 
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FIGURE  2.-  SYSTEM  DESCRIPTION 


FIGURE  3.-  STIFF  SPOTS  EFFECT  ON  LOCAL  TILE  STRESS 


stead  of  the  13  psi  originally  used  for  the  tile  strength.  This  caused  negative  structural  margins 
of  safety  to  exist  over  large  areas  of  the  structure  and,  in  certain  areas,  the  TPS  was  computed  to 
be  inadequate  to  survive  even  a single  mission. 

This  paper  will  cover  the  principal  design  issues,  tests,  and  analyses  required  to  solve  the 
tile  structural  integrity  problem  and  performance  based  on  the  recent  flight  test  program. 


Because  of  the  cost  and  schedule  limitations  imposed  on  the  Orbiter  project,  it  was  necessary  to 
begin  fabrication  and  installation  of  the  tiles  long  before  the  final  loads  and  stress  analysis  had 
been  completed.  When  large  numbers  of  tiles  were  found  to  have  inadequate  structure  margins,  the 
Orbiter  had  just  been  delivered  to  Kennedy  Space  Center  (KSC)  with  all  but  6000  of  the  33  000  tiles 
already  installed.  It  seemed  that  there  was  no  alternative  but  to  remove  every  tile  and  start  over 
(seriously  impacting  schedule  and  cost)  with  some  new  (as  yet  undeveloped)  stronger  tile  system.  The 
challenge  was  clear:  to  salvage  the  majority  of  the  installed  tiles  while  ensuring  sufficient  struc- 

tural margin  for  a safe  flight.  The  approach  devised  to  overcome  this  almost  insurmountable  chal- 
lenge was  the  so-called  Tile  Proof  Test.  The  proof  test  involved  the  application  of  a load  to  the 
installed  tile  so  as  to  induce  a stress  over  the  entire  footprint  equal  to  25  percent  above  the  maxi- 
mum flight  stress  experienced  at  the  most  critical  point  on  the  tile  footprint. 

To  fully  appreciate  the  value  of  this  proof  test,  it  is  necessary  to  understand  the  stress- 
inducing  environments  taken  into  consideration  when  computing  structural  margins.  In  addition  to  the 
local  flight-induced  loads  (caused  by  aerodynamics,  vibrations,  and  acoustic  noise)  and  local  sub- 
strate displacements  (structural  response  to  pressure  differential  and  acoustic  noise),  a value  of 
0.019  inch  (maximum  allowed  by  installation  specification)  of  tile/structural  mismatch  is  assumed  to 
exist  at  the  point  of  maximum  stress  (fig.  4).  Also,  since  this  brittle  TPS  material  has  a large 
scatter  in  the  strength  data,  the  low  99-percent  value  was  used  in  computing  margins  of  safety. 

Because  most  of  the  installed  tiles  would  be  stronger  than  the  statistically  derived  low 
strength  value,  and  since  most  of  the  tiles  would  realistically  not  have  the  maximum  mismatch,  it 
became  clear  that  if  the  tiles  were  proof  tested,  most  of  them  would  successfully  pass.  Therefore, 
this  approach  could  potentially  salvage  thousands  of  installed  tiles  and  only  a small  percentage 
would  fail  and  have  to  be  replaced.  The  tiles  that  would  fail  would  be  replaced  with  tiles  that  had 
been  densified  on  the  inner  moldline  surface.  The  device  used  for  this  proof  test  (fig.  5)  employs 
a vacuum  chuck  to  attach  to  the  tile,  a pneumatic  cylinder  to  apply  the  load,  and  six  pads  attached 
to  surrounding  tiles  to  react  the  load. 

Since  any  appreciable  tile  load  may  cause  some  internal  fibers  to  break,  it  was  essential  to  de- 
velop a means  of  evaluating  the  residual  strength  of  a tile  after  the  proof  test  had  been  performed. 
During  the  actual  proof  testing,  acoustic  sensors  (fig.  5)  placed  in  contact  with  the  tiles  were  used 
to  monitor  the  acoustic  emissions  from  any  internal  fiber  breakage.  A large-scale  laboratory  program 
was  initiated  to  arrive  at  a failure  criteria.  The  program  consisted  of  acoustically  monitorinq  many 
tiles  during  the  proof  loading  and  subsequently  inducing  cyclic  loads  (simulating  flight  values) 
until  failure  occurred  or  an  equivalent  of  100  missions  was  reached.  A pass/fail  criterion  was  es- 
tablished from  the  acoustic  signatures  of  the  tiles  both  failing  and  passing  the  laboratory  tests. 

The  proof  testing  of  installed  tiles  was  incorporated  and  not  only  salvaged  tens  of  thousands  of  in- 
stalled tiles  but  also  revealed  those  tiles  (13  percent  failing  proof  test)  with  inadequate  flight 
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PNEUMATIC  CYLINDER 


FIGURE  4.-  TILE  LOAD  SOURCES. 


FIGURE  5.-  PROOF  TESTING  DEVICE. 


LOAD/DEFLECTION  ALLOWABLE 


If  a tile  were  to  fail  during  the  proof  test,  it  would  be  removed,  the  bottom  of  the  tile  would 
be  densified  (with  a coat  of  colloidal  silica  particles),  and  the  newly  densified  tiles  reinstalled 
on  the  Orbiter.  This  densified  layer,  serving  the  function  of  a stiff  plate  on  the  tile  bottom,  elim- 
inates the  effect  of  local  stiff  spots  in  the  SIP  and  thus  increases  the  tile/SIP  system  strength 
from  6 to  13  psi  (fig.  6). 

However,  there  existed  a large  number  of  tiles  where  the  combined  loads  were  so  high  that  even 
this  doubled  system  strength  was  theoretically  not  adequate.  The  clear  challenge  was  to  exploit  any 
additional  densified  tile  strength  not  accounted  for  in  the  analysis.  This  challenge  was  success- 
fully met  by  the  incorporation  of  the  so-called  Stress  versus  Delta  (displacement)  allowable  curves. 
This  idea  was  conceived  by  realizing  that  the  combined  stresses  could  be  classified  into  those 
induced  by  external  loads  (aerodynamics,  vibrations,  acoustics)  and  those  induced  by  displacement 
(mismatch,  structural  out-of-plane  displacement  existing  under  the  tile).  It  is  the  displacement- 
induced  stresses  that  could  possibly  be  reduced  because  the  densified  layer,  being  stiff,  would  re- 
sist bending  and  thus  not  transmit  the  total  displacement  stress  to  the  virgin  RSI  material.  This  hy- 
pothesis was  supported  by  extensive  finite  element  analysis  (fig.  7).  The  solid  element  models  used 
in  this  analysis  indicated  a significant  reduction  of  peak  stresses  in  the  virgin  RSI  material  just 
above  the  densified  layer. 
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With  this  information  in  hand,  a test  program  was  initiated  to  test  numerous  densified  tiles  to 
failure  for  various  combinations  of  structural  displacement  and  external  loads.  The  test  arrangement 
is  shown  in  figures  8 and  9. 


FIGURE  8.-  TEST  SETUP  FOR  LOAD/DISPLACEMENT 
ALLOWABLES. 


FIGURE  9.-  TILE  SHOWING  FAILURE  SURFACE  DURING 
LOAD/DISPLACEMENT  TESTING. 


The  average  external  stress  level  (P/A)  at  which  each  densified  specimen  failed  was  then  plotted 
against  the  displacement  (Delta)  imposed  under  the  tile.  A bounding  curve  for  densified  tiles  was 
then  drawn  on  the  Stress  versus  Delta  plot.  The  results  are  shown  in  figure  10  together  with  similar 
data  for  undensified  tiles. 

The  results  obtained  provided  a method  by  which  externally  applied  stresses  and  displacement- 
induced  stresses  could  be  realistically  combined.  The  conservatism  of  simple  addition  of  all 
stresses  was  eliminated  and  the  full  capability  of  densified  tiles  could  be  used  to  replace  thousands 
of  highly  stressed  undensified  tiles. 


AIRFLOW  TEST  OF  SPECIAL  TILES 


During  both  ascent  and  entry,  the  TPS  is  subjected  to  numerous  loadings  from  a severe  aero- 
dynamic environment  including  shocks  and  pressure  gradients.  Through  development  testing  of  RSI 
material,  a basic  load  diagram  was  constructed  for  each  of  these  conditions  (fig.  11).  These  free- 
body  diagrams  make  the  analysis  of  square  or  rectangular  (acreage)  tiles  relatively  straightforward. 
However,  most  of  the  tiles  adjacent  to  tile  boundaries  (such  as  the  wing  leading  edge,  windshield, 
landing  gear  doo^s,  etc.)  do  not  have  such  simple  geometry.  These  special  tiles  are  often  located  in 
a very  complex  flow  field  and  because  of  their  unique  geometry  create  various  intricate  venting  paths 
that  can  not  be  easily  analyzed.  Therefore,  the  challenge  presented  was  to  ensure  the  structural  in- 
tegrity of  these  special  tiles  and  to  gain  a better  understanding  of  the  local  flow  conditions  around 
such  tiles.  To  meet  this  challenge,  a combination  of  flight  and  wind  tunnel  testing  was  initiated. 
Locations  (fig.  12)  from  several  of  the  most  complex  flow  fields  and  tile  geometries  were  chosen  to 
be  tested. 
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FIGURE  10.-  ALLOWABLE  FWT  IN  PRESENCE  OF  SUBSTRATE  DEFLECTION. 
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FIGURE  11.-  BASIC  LOAD  DIAGRAM. 
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FIGURE  12.-  TPS  FLOW  PROGRAM  TEST  ARTICLE  LOCATIONS. 


In  each  case,  the  local  aerodynamic  environment  of  the  Shuttle  (obtained  from  wind  tunnel  test- 
ing of  scale  models)  was  correlated  to  a similar  flow  field  existing  at  some  point  on  the  surface 
of  a high-performance  aircraft  or  in  a wind  tunnel  cross-section.  All  test  articles  were  constructed 
to  simulate  the  local  Orbiter  geometry.  The  tiles  were  heavily  instrumented  to  ensure  that  test  con- 
ditions achieved  were  within  the  predicted  aerodynamic  regimes  (fig.  13). 


A partial  summary  of  these  test  conditions  and  results  is  shown  in  table  1.  The  tests  not  only 
demonstrated  the  structural  integrity  of  each  tile  tested  but  increased  the  knowledge  of  flow  around, 
under,  and  through  the  TPS.  A more  detailed  treatment  of  tile  flow  tests  may  be  found  in  reference 
1. 

This  test  program  provided  a unique  solution  to  the  challenge  of  aerodynamic  loads  on  special 
tiles.  The  program  increased  confidence  in  TPS  design  by  identifying  design  deficiencies  which  were 
corrected  and  retested  to  ensure  their  reliability  during  future  flights. 


SPECIAL  PROBLEM  TILES 


Late  in  the  certification  program,  it  became  apparent  through  analysis  and  tests  that  a few 
unique  tiles  had  high  stress  levels  that  could  result  in  low  margins  of  safety  and/or  failure.  Each 
of  these  tiles  represented  a special  challenge  since  most  were  already  installed  on  the  Orbiter  and 
their  removal  or  redesign  could  severely  impact  a tight  launch  schedule.  Development  of  timely  reso- 
lutions to  these  special  tile  problems  presented  an  immense  challenge. 

Several  examples  of  the  challenges  met  and  the  techniques  used  are  described  in  the  following 
sections. 


WINDSHIELD  TILES 

During  ascent,  the  tiles  bordering  the  Orbiter  windshields  are  subjected  to  high  stagnation  pres- 
sures (fig.  14)  which  tend  to  lift  the  tiles.  Analysis  indicated  that  these  pressures  could  drive 
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FIGURE  13.-  TYPICAL  AIRFLOW  TEST  PANEL  ON  F-15  AIRCRAFT. 


the  SIP  bondline  stresses  above  the  RSI  material  allowables.  This  predicament  presented  a clear  chal- 
lenge; to  increase  the  strength  capability  of  these  tiles  while  maintaining  the  substructure  at  an  ac- 
ceptable temperature. 

The  windshield  tiles  (like  all  Orbiter  tiles)  are  machined  from  blocks  of  RSI  material  such  that 
the  layers  of  silica  material  run  in  a direction  generally  parallel  to  the  Shuttle  skin.  This  paral- 
lel grain  orientation  is  a thermal  requirement  to  minimize  the  conduction  of  heat  from  the  outer 
moldline  (OML)  to  the  inner  moldline  (IML).  However,  this  grain  orientation  causes  a reduction  of 
strength  (through  the  thickness)  because  of  the  relatively  low  number  of  vertically  running  fibers  be- 
tween the  silica  layers.  It  is  these  vertical  fibers  that  transfer  loads  to  the  structure.  A possi- 
ble solution  was  envisioned  where  the  tiles  directly  around  the  windshield  could  be  machined  with 
their  grain  running  perpendicular  to  the  Orbiter  skin.  This  would  provide  twice  the  strength  but 
would  create  the  possibility  of  overheating  the  structure.  Accordingly,  a thermal  analysis  was 
performed  with  tiles  whose  grain  was  oriented  in  a direction  perpendicular  to  the  Shuttle  skin.  In 
this  configuration,  more  heat  reached  the  aluminum  skin  as  expected,  but  the  heavy  framing  around  the 
windows  acted  as  a large  heat  sink  that  prevented  unacceptable  temperatures. 

As  a result  of  this  analysis,  the  tiles  around  the  windows  were  remachined  so  that  the  grain  ran 
perpendicular  to  the  Shuttle  skin.  While  this  significantly  increased  the  strength  of  the  tiles,  an 
adequate  margin  of  safety  was  not  quite  achieved.  A further  improvement  was  obtained  by  bonding  the 
RSI  material  that  overhung  the  window  glass  to  the  glass  itself  (fig.  14).  This  extra  area,  in  combi- 
nation with  the  grain  orientation,  provided  acceptable  margins  of  safety  for  flight. 


INSTALLED  TILE  DICING 

The  curved  forward  section  of  the  orbital  maneuvering  system  (OMS)  pod  is  covered  with  thin  8- 
by  8-inch  tiles  (fig.  15).  Shortly  before  the  first  flight  of  Columbia,  it  was  discovered  that  the 
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TABLE  1.-  SUMMARY  OF  AIRFLOW  TESTS 


Description 

Test 

facility 

Test 

conditions 

Results 

Elevon  trailing 
edge 

F-104 

Max  Q = 455  psf 

No  anomalies. 

ET  umbilical 
cavity 

AEDCa  16  ft 

Max  Q = 900  psf 

Thermal  barrier  frayed,  tiles  under  crossbeam  loosened,  and  baggie 
retainer  cord  damaged  tile  outer  moldline  (OML).  Redesigned  hard- 
ware tested  with  no  anomalies. 

Canopy  diced  tile 

Ames  11  ft 

Max  Q = 750  psf 

Three  tiles  came  off  and  several  loosened.  Pretest  OML  damage  did 
not  propagate.  Re-test  with  mini  tile  edges  bonded  to  filler 
bar  was  successful. 

Wing  leading 
edge  closeout 

F-15 

Max  Q * 1140  psf 

Gap  filler  (horsecollar)  migrated  beyond  OML  and  tiles  showed  ex- 
cessive deflection.  Redesigned  horsecollar  and  tile  support 
successfully  tested. 

Wing  glove 

F-15 

Max  Q = 1140  psf 

No  gap  filler  migration  and  tile  step  and  gap  change  less  than 
predicted.  Test  successful. 

ET  umbilical  door 

AEDC  16  ft 

Max  Q = 800  psf 

Flow  restrictors  failed  in  initial  test.  Redesign  successful. 

Vent  port  - FRSI 

Ames  11  ft 

Max  Q = 970  psf 

No  anomalies. 

Vent  port  - HRS  I 

Ames  11  ft 

Max  Q = 970  psf 

Limit  and  ultimate  load  portion  complete.  After  ultimate  condition 
was  reached,  portion  of  aft  tile  came  loose.  Life  testing  to 
continue. 

Windshield 
closeout  tiles 

F-15 

Max  Q = 1140  psf 

Initial  tests  indicated  high  net  airloads.  Redesign  tested.  No 
anomal ies. 

Wing  cove/el evon 

F-104 

Max  Q = 1125  psf 

No  anomalies. 

Shaved  tile/ 
mini  gap  fillers 

Ames  11  ft 

Max  Q = 650  psf 

No  anomalies. 

Vertical  tail 
leading  edge 

F-15 

Max  Q = 1140  psf 

No  anomalies. 

CLOT  - forward  fuselage 
acreage-calibration 
panel 

LaRCb  8 ft 

Over  90  min  of 
shock  from  bipod 

No  anomalies. 

aArnold  Engineering  Development  Center. 
bLangley  Research  Center. 


revised  combined  loads  on  the  OMS  pod  structure  would  produce  considerably  higher  deflections  than 
previously  anticipated.  Since  thin  tiles  are  relatively  weak  under  a bending  load,  the  increase  in 
predicted  deflections  could  cause  these  fragile  tiles  to  fracture  and  possibly  separate  from  the  OMS 
pod.  The  challenge  then  became  how  to  reduce  the  effect  of  these  increased  deflections  on  tiles  al- 
ready installed  without  requiring  their  removal.  The  approach  pursued  was  to  develop  a vehicle 
dicing  procedure  (fig.  16)  whereby  the  larger  8-  by  8-inch  tiles  were  cut  into  smaller  pieces  which 
could  more  easily  accommodate  the  high  structure  deflections. 


Dicing  had  previously  been  used  to  reduce  deformation-induced  stress  and  to  aid  in  the  installa- 
tion of  thin  tiles  but  the  tiles  were  always  diced  before  installation.  To  perform  the  operation  on 
the  Orbiter,  special  tools  were  developed  and  the  cutting  carefully  monitored  to  ensure  the  desired 
cuts  were  made  without  damage  to  tile  or  substrate.  This  procedure  was  successfully  performed  on  the 
OMS  pod  and  later  in  other  areas  of  the  vehicle  thus  providing  a timely  solution  to  a challenging 
problem  and  salvaging  hundreds  of  tiles. 


AUGER 

During  the  calculation  of  flight  stresses  for  the  body  flap  tiles,  it  was  determined  that  the 
trailing  edge  corner  tiles  did  not  have  adequate  margins  of  safety  for  the  predicted  vibration  and 
acoustic  loads  during  lift-off  (fig.  17).  This  was  later  confirmed  during  the  acoustic  testing  of 
the  body  flap  when  both  corner  tiles  (weighing  approximately  6 pounds)  failed  within  seconds  of  start- 
up. These  LI2200  corner  tiles  are  overhung  in  two  directions,  thus  creating  a large  overturning 
moment  on  a small  SIP  area  and  correspondingly  high  tension  stress.  But  even  more  significant  than 
the  stress  levels  was  the  inability  of  the  SIP  to  withstand  this  high  cyclic  loading.  The  challenge 
therefore  became  twofold:  (1)  how  to  prevent  failure  caused  by  high  RSI  tensile  stress,  and  (2)  how 

to  prevent  the  SIP  from  failing  because  of  the  high  values  of  cyclic  loading  experienced  on  the  body 
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FIGURE  14.-  WINDSHIELD  TILES. 
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FIGURE  15.-  QMS  POD  TILES. 


FIGURE  16.-  EFFECTS  OF  DICING. 


flap.  To  increase  the  capability  of  the  corner  tile  for  high  oscillatory  load,  a mechanical  attach- 
ment developed  earlier  called  the  Auger  was  considered.  The  auger  system  (fig.  18)  is  twisted  into 
a tile  and  then  attached  to  the  substructure  by  bolts. 
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FIGURE  17.-  BODY  FLAP  CORNER  TILE.  FIGURE  18.-  AUGER  TILE  ATTACHMENT. 


The  key  component  of  this  system  is  the  use  of  Belville  washers  to  preload  the  auger  itself 
with  a tension  load  while  at  the  same  time  inducing  a compression  stress  in  the  SIP.  The  preloaded 
washers  (acting  as  a soft  spring)  and  the  compressed  SIP  (acting  as  a stiff  spring)  then  worked 
together  as  a parallel  spring  system.  The  stiff  SIP,  since  it  is  greatly  compressed,  takes  most 
of  the  external  cyclic  loading,  while  the  Belville  washers  help  prevent  significant  cyclic  loads 
from  being  induced  by  the  auger  into  the  intolerant  RSI  material.  The  auger  system  is  preloaded 
to  a high  enough  level  that  the  SIP  remains  in  compression  throughout  the  flight  environment, 
and  the  tension  sensitive  bondline  is  prevented  from  experiencing  a high  tensile  loading  (see 
load  diagrams  in  figures  19  and  20).  The  auger  system  has  been  fully  certified  by  test  for  100 
missions  and  has  flown  successfully  on  both  0V102  and  0V099. 


GAP  FILLERS  AND  FILLER  BAR  BONDS 

Two  other  on-the-Orbiter  techniques  were  developed  to  meet  the  challenge  of  salvaging  tiles  with 
high  shock-induced  stresses  in  a timely  manner.  One  of  these  "fixes"  involved  thick  tiles  (usually 
on  the  lower  surface)  with  a relatively  small  footprint.  As  shocks  sweep  over  these  tiles,  they 
would  tend  to  rotate  inducing  high  stresses  at  the  SIP/tile  bondline  (fig.  21).  To  reduce  this 
shock-induced  overturning  moment,  gap  fillers  were  installed.  Once  contacted  by  the  rotating  tile, 
a gap  filler  will  create  a horizontal  reaction  that  acts  against  the  overturning  moment  and  reduces 
bondline  stresses. 

However,  for  thin  tiles  (usually  found  on  the  upper  surface)  a gap  filler  "fix"  would  not  effi- 
ciently reduce  a shock-induced  stress  to  acceptable  levels.  Therefore,  a second  on-the-vehicle  tech- 
nique was  developed  in  which  the  filler  bar  surrounding  the  SIP  was  bonded  to  the  tile.  This  was 
done  by  inserting  a crooked  needle  into  the  tile-to-tile  gap  and  depositing  RTV  on  top  of  the  filler 
bar  where  the  additional  bond  area  is  desired  (fig.  21).  This  extra  bond  area  significantly  increases 
the  total  bonded  footprint  and  decreases  the  effects  of  a shock-imposed  overturning  moment. 

Both  of  these  techniques  have  been  selectively  implemented  where  analysis  indicated  shock- 
induced  stresses  were  exceeding  allowables  and  needed  to  be  reduced  significantly. 

The  special  tiles  examples  presented  in  these  sections  affected  very  few  tiles  but  their  resolu- 
tion contributed  greatly  to  the  highly  successful  Shuttle  flights. 


CONCLUDING  REMARKS 


A wise  man  once  stated,  "It  is  better  to  attempt  a gigantic  endeavor  but  fall  slightly  short 
than  to  attempt  very  little  and  be  highly  successful."  The  Space  Shuttle  and  indeed  the  development 
of  the  TPS  tiles  was  such  a gigantic  endeavor  but  it  was  almost  flawlessly  achieved.  In  this  paper, 
the  focus  was  on  the  challenges  and  technical  resolution  of  the  tile  structural  integrity;  however, 
it  should  be  emphasized  that  the  challenges  were  resolved  in  an  environment  of  tight  cost,  tight 
schedule,  and  high  public  visibility.  This  environment  necessitated  the  practical  resolution 
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TILE/AUGER  STRESS  ANALYSIS 


TILE  LOAD 


FIGURE  19.-  FREE-BODY  DIAGRAM  OF  HIGHLY  LOADED 
AUGER  TILE. 


FIGURE  20.-  FREE-BODY  DIAGRAM  OF  HIGHLY  LOADED 
AUGER  TILES. 


afforded  first  by  the  Proof  Test  (affecting  tens  of  thousands  of  tiles),  later  by  the  Load  versus 
Delta  curves  (affecting  thousands  of  tiles),  and  the  Airflow  Tests  (affecting  hundreds  of  tiles),  and 
finally  by  the  Special  Tile  Fixes  (affecting  small  numbers  of  tiles).  It  is  in  this  emphasis  on  the 
most  timely  resolution  of  the  tile  structural  challenges  that  the  program  should  feel  much  pride. 
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FIGURE  21.-  SCHEMATIC  OF  A TILE  AND  GAP  FILLER  INSTALLATION. 
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ABSTRACT 


The  Orbiter  atmospheric  revitalization  subsystem  provides  thermal  and  contaminant  control  as 
well  as  total-  and  oxygen  partial-pressure  control  of  the  environment  within  the  Orbiter  crew  cabin. 
Challenges  that  occurred  during  the  development  of  this  subsystem  for  the  Space  Shuttle  Orbiter  are 
described  in  this  paper.  The  design  of  the  rotating  hardware  elements  of  the  system  (pumps,  fans, 
etc.)  required  significant  development  to  meet  the  requirements  of  long  service  life,  maintainability, 
and  high  cycle-fatigue  life.  As  a result,  a stringent  development  program,  particularly  in  the  areas 
of  bearing  life  and  heat  dissipation,  was  required.  Another  area  requiring  significant  development 
was  cabin  humidity  control  and  condensate  collection.  The  requirements  for  this  element  of  the  sys- 
tem include  long  life,  ease  of  maintenance,  and  bacteria  growth  control.  These  were  combined  with 
the  requirement  to  handle  a wide  range  of  operating  conditions  in  the  zero-g  environment.  Innova- 
tive solutions  required  to  resolve  problems  that  arose  during  design  and  qualification  of  the  pres- 
sure control  system  include  a vibrating  wire  and  associated  electronics  to  quantify  the  rate  of  cabin 
pressure  change;  magnets  and  electronics  to  accomplish  noninvasive  valve-position  indication;  power- 
saver  electronics  for  hold-open  solenoids  combined  with  a f ai led-closed  capability  upon  loss  of 
power;  oxygen-compatible,  high-pressure,  motor-operated  latching  valves  using  pressure-balancing 
metal  bellows;  a five-way,  two-position  manual  valve  to  protect  the  cabin  pressure  regulator  from  as- 
cent-induced vibration;  high-accuracy,  long-life  oxygen  partial-pressure  sensors;  and  accurate 
oxygen/nitrogen  flow  sensors. 


INTRODUCTION 


The  environmental  control  systems  (ECS's)  for  Project  Mercury  and  the  Gemini  and  Apollo  Programs 
were  all  designed  for  single-mission  use.  Although  high  reliability  of  this  hardware  was  essential, 
the  requirement  for  multimission  use  was  not  a principal  design  consideration.  In  contrast,  the 
Orbiter  design  requirement  is  for  an  extended  multimission  capability,  which  requires  the  combination 
of  the  high-reliability  technology  developed  during  the  preceding  programs  with  the  capability  to 
withstand  the  induced  and  operational  environments  of  the  Shuttle  Orbiter  to  produce  an  ECS  with  100- 
mission  life.  These  requirements  resulted  in  several  interesting  challenges  to  be  solved  during  the 
design,  development,  certification,  and  final  verification  of  the  various  elements  of  the  Orbiter 
atmospheric  revitalization  subsystem  (ARS). 


ORBITER  ARS  COMPONENT  DEVELOPMENT 


ROTATING  ELEMENTS 

The  design  of  the  rotating  elements  contained  in  the  Shuttle  Orbiter  ARS  was  considered  quite 
sensitive  to  this  unique  concept  of  multiple  mission  use.  The  specific  requirements  and  problem 
areas  that  had  an  impact  on  the  design  of  the  fans,  the  pumps,  and  the  water  separator  were  as 
follows. 


1.  Long-term  operating  life  - 10  000  hours  for  the  bearing  system 

2.  High  environmental  load  levels  - as  much  as  ±25g  vibration 
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3. 

High  cycle-fatigue  life  - approximately  10^  cycles 

OF 

4. 

Minimum  weight 

5. 

Thermal  environment 

6. 

Maintainabil ity 

7. 

No  external  liquid  leakage 

8. 

Corrosion  considerations  (galvanic  and/or  environmental 

compatibility) 

9. 

Self-generated  and  system-borne  contamination 

10. 

Fluid  properties 

■""Ml  Pi  . 
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Motors 


The  impact  of  the  design  requirements  affected  the  design  of  the  electric  motors  that  power  the 
fans,  the  pumps,  and  the  water  separator  as  applied  to  the  electric  motor  efficiency  and  shaft  bear- 
ing life.  Motor  efficiency  is  improved  as  the  gap  between  the  rotor  and  the  stator  is  reduced.  Motor 
manufacturers  try  to  optimize  the  combination  of  shaft  size,  manufacturing  tolerances,  and  shaft 
stiffness  to  achieve  best  overall  efficiency.  The  unusually  high  environmental  loads  (shock  and 
vibration)  induced  by  the  Orbiter  required  close  attention  to  reducing  shaft  deflection  and  manu- 
facturing tolerances  to  meet  the  minimum  motor  efficiency  target  (q  = 60  percent). 

The  long-operating-life  requirement  coupled  with  the  high-level  environmental  loads  made  the 
bearing  selection  a very  critical  design  task.  To  maximize  bearing  life,  choice  of  the  bearing  type 
and  the  lubricant  required  close  cooperation  between  the  various  suppliers  and  a carefully  conceived 
development  program.  The  bearings  as  finally  selected  are  precision,  deep-groove,  angular-contact 
ball  bearings  that  are  sealed  and  lubricated  with  Andok  C grease.  The  success  of  the  bearing  design 
is  proven  by  the  fact  that  there  have  been  no  flight  failures  and  fans  have  demonstrated  operating 
lives  far  in  excess  of  the  design  requirement.  A cabin  fan  has  accumulated  in  excess  of  56  000  hours 
of  operation  and  an  avionics  fan  in  excess  of  28  000  hours.  The  cross  section  in  figure  1 is  typi- 
cal for  the  various  electric  motors  used  in  the  Shuttle  Orbiter  ARS. 


FIGURE  1.-  CABIN  AIR  FAN  MOTOR. 
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Pumps 


Design  of  the  fluid  pumps  was  severely  impacted  by  the  Space  Shuttle  requirements.  The  restric- 
tion on  external  leakage,  the  long  operating  life,  and  the  short  turnaround  time  between  launches 
precluded  the  use  of  a dynamic  shaft  seal  between  the  motor  and  the  pump.  The  choice  was  immediately 
reduced  to  either  a magnetic-coupling  pump  drive  or  an  immersed  motor.  The  flowthrough  (immersed) 
motor  design  was  selected  after  a trade-off  study  revealed  the  following. 

1.  The  magnetic  coupling  is  more  costly. 

2.  The  magnetic-coupling  configuration  is  heavier. 

3.  The  magnetic-coupling  drive  results  in  a lower  operating  efficiency. 

4.  The  immersed  motor  uses  the  pumped  fluid  for  its  coolant,  whereas  the  magnetic-coupling  de- 
sign effectively  insulates  the  motor  and  thereby  accrues  substantial  weight  penalty  in  providing  a 
conductive  heat  path  to  a thermal  ground. 

The  immersed  motor  uses  hydrodynamic  sleeve  bearings  because  antifriction  (ball)  bearings  when  run- 
ning immersed  develop  excessive  friction,  which  shortens  life.  A second  consideration  that  rein- 
forced the  use  of  sleeve  bearings  was  the  lubrication  properties  of  the  operating  fluid,  water. 

Water  is  not  a good  lubricant.  However,  carbon-sleeve  bearings  can  even  be  run  dry  without  galling, 
chipping,  or  spalling.  The  performance  of  antifriction  bearings  is  degraded  by  operation  in  water. 

Even  though  carbon-sleeve  bearings  have  desirable  properties,  the  actual  design  of  the  bearings 
was  complicated  by  the  conflicting  bearing  requirements.  The  bearings  must  operate  with  minimum  fric- 
tion in  a zero-g  environment  and  in  a very  high  g-level  vibratory  environment  and  must  not  sustain  vi- 
bration damage  when  not  operating  in  the  very  high  g-level  environment.  The  bearings  that  finally 
evolved  are  high-precision  parts  for  which  very  close  control  of  the  bearing/journal  clearance  (i.e., 
radial  clearance  is  0.0004  to  0.0008  inch)  is  maintained  to  (1)  prevent  overloading  during  high-g  op- 
eration, (2)  prevent  the  development  of  the  self-destructive  half-speed  shaft  whirl  while  operating 
in  zero  g,  (3)  prevent  impact  damage  during  nonoperating  vibration  periods,  and  (4)  allow  minimum 
armature/stator  clearance  for  maximum  motor  efficiency.  (The  overall  pump  efficiency  is  approxi- 
mately 36  percent.) 

Combating  the  effects  of  fluid  contamination  was  a very  important  consideration.  The  steps 
taken  to  reduce  the  potential  wear  problems  include  the  following. 

1.  Precision  clean  the  pump  as  a detail  item. 

2.  Install  "last  chance"  filters  to  prevent  the  ingestion  of  foreign  particles  during  handling. 

3.  Adjust  operating  clearances  to  minimize  pump  sensitivity  to  contamination. 

4.  Provide  a fine-level,  high-capacity  filter  in  the  pump  package  on  the  inlet  side  of  the  pump. 

The  design  adequacy  of  the  various  pumps  and  motors  was  demonstrated  by  successful  performance  in 
passing  development  and  qualification  testing,  in  ground  operation,  and,  ultimately,  in  actual  mis- 
sion operation.  A water  pump  (fig.  2)  has  accumulated  42  000  hours  of  ground  test  operation,  which 
demonstrates  the  capability  of  the  fluid  pump  design. 


Water  Separator 


The  water  separator  is  also  a Shuttle  generation  device  with  little  or  no  previous  flight  his- 
tory. It  is  constructed  of  two  primary  components:  a fan/separator  and  a pitot  pump.  Although  a ro- 

tary separator  and  pitot  pump  assembly  was  flown  on  the  Apollo  lunar  module,  it  was  a freewheeling 
turbine-driven  device.  The  Shuttle  separator  is  driven  by  an  eight-pole,  400-hertz,  three-phase  syn- 
chronous electric  motor,  which  also  drives  the  fan  on  the  same  shaft. 

The  motor-driven  system  is  superior  to  the  turbine  separator.  Startup  is  a matter  of  turning  a 
switch  to  initiate  suction  at  the  slurper,  and  the  humidity  control  system  is  ready  to  function.  The 
turbine  separator  was  dependent  on  airstream  energy  to  develop  adequate  power  to  drive  the  turbine. 
This  dependence  required  oversizing  the  air  recirculation  fan  and  motor.  If  this  approach  were  taken 
with  the  Orbiter,  the  total  power  consumption  would  increase  significantly  since  a turbine  would  im- 
pose a significant  additional  pressure  drop.  The  unique  concept  of  the  Shuttle  separator  is  removing 
condensate  with  only  2 to  2.5  percent  of  the  airstream  flow  rate.  Figure  3 illustrates  the  fan/ 
separator. 
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After  the  condensate  is  centrif ugally  separated  from  the  return  air  to  the  cabin,  a pitot  pump 
is  employed  to  pump  the  fluid  into  the  wastewater  tank.  At  a speed  of  approximately  5900  rpm,  the 
pitot  pump  generates  38  to  40  psi  at  a flow  rate  of  3.5  to  4.0  lb/hr.  The  pitot  pump  has  been  used 
extensively  in  previous  programs  because  it  is  conducive  to  these  pumping  conditions.  The  pump  must 
overcome  the  pressure  drop  of  two  ball  relief  check  valves  and  the  plumbing  to  the  waste  tank.  These 
check  valves  prevent  the  backflow  of  wastewater  into  the  cabin  and  provide  sufficient  backpressure  on 
the  pitot  pump  to  prevent  the  pumping  of  gas  into  the  waste  system. 

Redundant  fan  separators  are  used  on  the  Shuttle;  one  operates  at  all  times  both  on  the  ground 
and  in  flight.  This  continuous  operation  gives  the  cabin  environment  a reliable  humidity  control 
system. 


HUMIDITY  CONTROL  SYSTEM 

Humidity  control  for  manned  spacecraft  is  a necessary  part  of  the  total  environmental  control 
and  life  support  system.  Proper  atmospheric  water  content  is  required  for  crew  comfort,  for  protec- 
tion of  avionic  and  other  electronic  equipment,  and  to  prevent  the  growth  of  fungi  and  bacteria.  In 
addition,  high  humidity  levels  can  result  in  annoying  problems  such  as  condensation  on  windows,  walls, 
and  optical  equipment.  Compared  to  dehumidification  systems  for  aircraft,  design  of  a humidity  con- 
trol system  for  spacecraft  is  more  challenging  because  of  the  absence  of  gravitational  force.  Con- 
densate removal  and  storage  requires  the  use  of  capillary  devices  and/or  rotating  machinery  to  pro- 
duce artificial  gravity. 

The  advent  of  the  Shuttle  Program  necessitated  longer  life  and  lower  maintenance  equipment. 

Rapid  turnaround  of  the  Orbiter  following  each  mission  was  a prerequisite.  These  requirements 
prompted  the  need  for  an  improved  humidity  control  subsystem. 

The  humidity  control  system  is  composed  of  three  essential  elements:  a condenser,  a water 

collector,  and  a separator/pump  assembly.  A plate-fin  heat  exchanger  was  selected  for  the  condenser 
with  a four-pass,  cross-counterf low  coolant  loop.  The  plate-fin  design  provides  excellent  perform- 
ance and  lightweight.  To  improve  temperature  distribution  and  provide  a free  core  face  for  conden- 
sate collection,  a cross-counterflow  approach  was  necessary.  This  arrangement  also  increased  coolant 
velocity,  which  minimized  flow  distribution  problems  and  resulted  in  more  uniform  core  temperatures. 
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FIGURE  3.-  SCHEMATIC  OF  ROTARY  SEPARATOR. 


Condensate  collection  was  achieved  with  the  use  of  a slurper  bar  (fig.  4).  The  slurper  is  the 
heart  of  the  system,  and,  although  it  had  never  been  flown  before  the  Shuttle  Program,  the  slurper 
concept  was  selected  over  two  other  methods  that  had  been  successfully  flown  previously. 

One  of  the  options  available  was  the  "elbow  separator  and  scupper,"  which  collects  water  down- 
stream of  the  core  in  the  main  airstream  outlet  duct.  The  advantages  of  the  elbow  and  scupper  were 
ease  of  maintenance,  simplicity,  and  freedom  from  wicks.  Wicks  are  undesirable  for  any  long-term  use 
since  they  are  susceptible  to  contamination.  Disadvantages  of  the  "elbow/scupper"  concept  are  high 
pressure  drop,  which  results  in  increased  fan  power,  and  inadequate  handling  of  surges.  Surges  of 
condensate  are  released  from  the  condenser  at  intervals  when  sufficient  core-pressure  drop  has 
developed  to  overcome  the  capillary  head-pressure  rise  of  the  fin  passages.  As  one  section  of  the 
core  is  "blown"  free,  another  section  is  undergoing  the  condensation  process  and  buildup  of  water. 
Deficiency  of  the  scupper  in  handling  surges  results  in  some  carryover  into  the  cabin  airstream. 

A second  option  is  the  use  of  a wick  at  the  face  of  the  condenser  to  draw  away  the  water  from 
the  airstream.  The  advantages  of  a wick  are  low  pressure  drop  and,  in  the  case  of  an  integral  wick, 
lower  probability  of  surge  occurrence.  A disadvantage  of  the  wick  concept  is  the  need  for  some  type 
of  startup  procedure  by  which  the  wick  is  prewetted.  This  requirement  is  inconsistent  with  Orbiter 
operating  philosophy. 

In  view  of  these  considerations,  the  slurper  becomes  an  attractive  device.  It  incorporates  the 
advantages  of  the  other  systems  and  minimizes  or  eliminates  the  disadvantages.  With  a suction  of  2 
to  2.5  inches  of  water  provided  across  the  slurper  holes  by  the  fan/separator  unit,  the  slurper  can 
separate  as  much  as  3.5  to  4.0  Ib/hr  of  condensate.  The  slurper  has  the  advantages  of  a wick  in 
terms  of  pressure  drop  and  surge  protection.  A hydrophilic  coating  on  the  surface  surrounding  the 
0.020-inch-diameter  holes  provides  a wettable  surface,  which  has  "wicking"  capability  to  draw  water 
into  the  holes.  Main  airstream  pressure  drop  is  not  affected,  and  only  2 to  2.5  percent  of  the  air- 
flow rate  is  bled  from  the  stream  by  the  fan/separator  and  is  returned  to  the  cabin  after  condensate 
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FIGURE  4.-  DETAIL  VIEW  OF  SLURPER. 


removal.  The  slurper  capability  to  handle  the  transient  condensation  process  has  been  demonstrated 
in  testing  and  in  six  Shuttle  flights. 

Incorporation  of  the  slurper  into  a heat  exchanger  is  illustrated  in  figure  4.  The  slurper  is 
purely  an  extension  of  the  coolant  passage  closure  bar  and,  in  this  location,  has  the  advantages  of 
a face  wick.  The  slurper  requires  minimum  maintenance.  It  was  discovered  during  the  first  Shuttle 
flights  that  a considerable  amount  of  lint  and  fibers  did  plug  many  of  the  holes.  Backflushing  was 
required  to  clean  the  holes  and  some  vacuuming  to  remove  the  contamination.  If  a wick  were  present, 
it  definitely  would  be  rendered  useless  since  the  lint  fibers  would  have  penetrated  deep  into  the 
wick  matrix  to  create  a difficult  and  time-consuming  cleaning  process. 


PRESSURE  CONTROL  SYSTEM 

Rapidly  increasing  or  decreasing  pressure  within  the  atmosphere  of  the  Space  Shuttle  Orbiter  is 
often  indicative  of  a malfunction  that  may  endanger  the  crewmembers  or  the  mission.  A ruptured  pneu- 
matic line  (pressure  increase)  within  the  flightcrew  compartment  or  a puncture  in  the  compartment's 
pressure  barrier  (pressure  decrease)  are  extreme  examples  of  such  malfunctions.  The  need  for  a de- 
vice capable  of  providing  a warning,  in  "real  time,"  as  contrasted  to  a graph  that  provides  histori- 
cal data  of  events  that  have  previously  transpired  is  obvious.  Such  a device  should  also  relieve 
crewmembers  of  constant  visual  monitoring  and  interpretation  of  graphs. 


Pressure  Decay  Sensor 


The  pressure  decay  sensor  produces  an  electrical  signal  that  accurately  represents  the  actual 
instantaneous  pressure  change  in  the  cabin.  The  electrical  signal  produced  by  the  pressure  decay 
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sensor  is  visually  displayed  and  is  interfaced  with  caution  and  warning  devices  that  alert  crew- 
members to  the  necessity  of  immediate  corrective  measures.  This  same  electrical  signal  is  tele- 
metered to  Earth  monitoring  stations. 

The  natural  resonant  frequency  of  a fine  wire  varies  with  the  tension  on  the  wire.  The  wire  is 
driven  by  an  oscillating  current  in  the  wire  acting  in  a permanent  magnetic  field.  The  wire  is  part 
of  the  electrical  driving  circuit;  therefore,  the  circuit  oscillates  at  the  resonant  frequency  of  the 
wire.  The  cabin  atmospheric  pressure  acting  upon  a metal  bellows  aneroid  varies  the  wire  tension  and 
thus  the  frequency  becomes  a function  of  the  atmospheric  pressure.  The  cabin  pressure  rate  of  change 
is  continuously  calculated  from  the  frequency  and  expressed  as  an  output  voltage. 

The  electronic  circuit  boards  that  comprise  the  rate  electronics  portion  of  the  decay  sensor 
must  withstand  exposure  to  the  cabin  environmental  conditions  of  relative  humidity  as  great  as  100 
percent,  salinity  of  1 percent  by  weight,  temperatures  of  -12°  to  120°  F,  and  pressure  from  4.8  psia 
to  15  psig.  These  circuit  boards  are  therefore  mounted  in  a sealed,  anodized  aluminum  enclosure  that 
is  vented  through  a water-shedding  surfactant  filter.  Additionally,  each  circuit  board  is  protected 
by  a coating  of  approved  silicone  rubber.  Unit  interfacing  is  accomplished  through  two  hermetically 
sealed  electronic  receptacles.  The  pressure  transducer  portion  of  the  decay  sensor,  except  for  the 
pressure  port,  is  hermetically  sealed.  The  pressure  port  is  open  to  the  vibrating  wire  through  a 
surfactant  filter  that  protects  against  moisture  and  contamination.  Unit  venting  through  surfactant 
filters  coupled  with  the  hermetic  seals  incorporated  in  the  design  of  the  decay  sensor  also  protect 
the  unit  from  sand  and  dust. 

Specified  g-levels  corresponding  to  specific  phases  of  Shuttle  operation  were  3.3g  in  the  longi- 
tudinal axis  and  2.8g  in  the  vertical  axis.  Through  testing,  it  was  determined  that  the  pressure 
transducer  anvil  transmits  the  force  of  the  aneroid  to  the  vibrating  wire.  The  mass  of  the  anvil  was 
reduced  and  thereby  the  effects  of  the  specified  g-loadings  were  minimized.  Additionally,  the  least 
sensitive  axis  of  the  pressure  transducer  was  oriented  in  the  atmospheric  revitalization  pressure  con- 
trol system  (ARPCS)  control  panel  to  aline  with  the  Shuttle  axis  subject  to  the  greatest  g-level. 

Each  circuit  board  in  the  rate  electronics  portion  of  the  decay  sensor  is  fully  supported;  thus,  flex- 
ing at  the  g-levels  specified  is  eliminated. 

The  suspended  (free)  portions  of  the  pressure  transducer  (aneroid,  vibration  wire,  and  anvil) 
have  been  designed  for  high  strength-to-mass  ratio  to  maximize  resistance  to  the  rectangular  pulses 
of  various  g-levels,  in  the  minus-Z  direction,  experienced  during  landing.  The  initial  design  change 
called  for  tapered  ends  on  the  vibrating  wire,  appropriate  configuration  of  the  anvil,  and  minimal 
aneroid  size  without  affecting  sensitivity.  During  testing,  however,  it  was  discovered  that  the 
tapered  ends  of  the  vibrating  wire  tended  to  fracture.  The  new  configuration  calls  for  a chemically 
machined,  square  wire  with  wide  ends  and  narrow  center  section.  Testing  has  proven  this  configura- 
tion to  be  the  best  suited  to  rectangular  pulses. 

Required  operating  life  is  a minimum  of  20  000  hours  over  a 10-year  period.  Early  decay  sensor 
designs  encountered  problem  areas.  Small  fractures  in  the  vibrating  wire  were  observed  at  the  vibra- 
tion nodes,  and  cracks  were  observed  at  the  welded  seam  joining  the  two  formed  disks  of  the  sealed 
bellows.  The  new  chemically  machined,  square-cross-section  vibrating  wire  with  wider  ends  eliminated 
fractures  in  the  vibrating  wire.  Brazing  replaced  welding  of  the  two  formed  disks  of  the  sealed 
aneroid  bellows.  This  change  resulted  in  lower  residual  stress  and  reduced  contamination  in  the  axis 
of  attachment.  The  insulator  at  the  electrically  insulated  end  of  the  vibrating  wire  was  also  changed 
from  fired  lava  to  machined  alumina,  which  resulted  in  improved  resistance  to  fatigue  stress,  enhanced 
dimensional  stability,  and  relief  from  low-rate,  continuous  drop  in  resonant  frequency.  In  addition, 
the  anvil  mass  was  redesigned  to  the  absolute  minimum  and  the  assembly  technique  incorporated  an  ad- 
justment to  establish  "zero"  inherent  twist  in  the  vibrating  wire.  These  measures  eliminated  all  ex- 
traneous modes  of  vibration  except  for  the  desired  mode. 


Pressure-Balanced  Latching  Valve 


The  pressure-balanced  latching  valve  is  used  to  control  the  combined  flow  of  oxygen  (0^)  and  ni- 
trogen (N2)  at  a pressure  of  3300  psi - During  the  Skylab  Program,  a solenoid  valve  that  weighed  4.35 
pounds  was  used  for  a similar  requirement.  Weight  limitations  imposed  in  the  Space  Shuttle  Program 
required  a much  lighter  valve.  The  Skylab  valve  solenoid  coils  accounted  for  a majority  of  this 
weight.  The  Shuttle  version,  which  has  an  overall  weight  of  1.5  pounds,  incorporates  an  electric 
motor  drive  and  screw  arrangement. 

The  latching  function  of  the  pressure-balanced  latching  valve  is  provided  by  a bistable  Belle- 
ville spring.  The  electric  motor  drives  the  valve  stem  and  the  Belleville  spring  in  the  same  direc- 
tion. After  actuation  from  either  stable  region  (open  or  closed),  the  spring  "snaps  through"  and 
retains  the  valve  in  the  selected  position.  The  Belleville  spring  provides  a positive  mechanical 
latch  that  is  unaffected  by  vibration  and  shock  conditions. 
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As  its  name  indicates,  the  latching  valve  is  pressure  balanced.  Simply  stated,  the  force  re- 
quired to  either  actuate  or  deactuate  the  valve  is  not  affected  by  the  level  of  inlet  or  outlet 
pressures  controlled  by  the  valve.  This  pressure  balancing  is  accomplished  by  making  the  effective 
areas  of  both  the  bellows  and  the  orifice  identical.  Valve  reliability  has  been  greatly  increased  by 
the  employment  of  a triple-wall,  electrodeposited  nickel  bellows.  This  bellows  configuration  elimi- 
nates the  necessity  of  dynamic  seals.  The  0-ring  seals  used  on  the  pressure-balanced  latching  valve 
are  secondary  seals  only. 


Power  Saver 


Two  large  nonlatching,  normally  closed,  solenoid-operated  valves  are  used  in  the  N2/O2  control 
panel.  Design  parameters  dictate  that  these  two  valves  "fail  safe"  in  the  closed  position  in  the 
event  of  power  failure.  Hence,  mechanical  or  magnetic  latching  is  not  feasible.  These  valves  re- 
quire two  distinct  operating  power  levels:  the  "actuating"  level  and  the  "holding"  level.  The 
actuating  level  requires  high  power  to  overcome  friction  and  move  the  armature  or  valve  stem  to  the 
operated  position;  the  holding  level  requires  10  to  25  percent  of  the  power  needed  in  the  actuating 
level  to  maintain  the  valve  in  the  operated  position.  Although  the  holding  power  level  is  greatly 
reduced  from  the  actuating  level,  the  power  drain  is  still  significant.  The  holding  power  must  be 
applied  on  a continuous  basis  because  the  valves  do  not  have  mechanical  or  magnetic  latching  devices. 

Two  basic  methods  are  commonly  employed  to  maintain  a non-latching-type  solenoid  valve  in  the 
operated  position.  The  first  method  is  the  continuous  application  of  power  at  the  actuating  level. 
This  method  tends  to  cause  serious  overheating  and  power  requirement  problems.  An  alternate  method 
is  the  use  of  an  additional  switch  and  resistor  circuit.  The  overheating  of  the  solenoid  coil  is 
eliminated;  however,  the  heating  problem  is  now  switched  to  the  resistor. 

The  power  saver  is  an  alternative  to  the  two  previously  applied  methods.  The  power  saver  is 
connected  between  the  solenoid  valve  and  the  power  source,  and  automatically  sequences  power  to  the 
solenoid  without  the  use  of  resistors.  Hence,  excessive  overheating  and  excessive  power  loss  due 
to  increased  line  resistance  is  eliminated.  Upon  solenoid  circuit  initiation,  power  from  the  power 
source  passes  through  the  power  saver  and  is  applied  to  the  solenoid  valve  at  the  actuating  level. 
After  actuation  (usually  1/2  second  or  less),  the  power  saver  automatically  reduces  applied  power 
to  the  holding  level. 

Initially,  the  power  saver  provides  full  actuating  power  to  the  solenoid  coil  from  the  power 
source.  This  full  power  is  supplied  until  the  power  saver  senses  some  preset  current  level  in  the  so- 
lenoid coil;  application  of  power  is  then  discontinued.  Discontinuation  of  power  allows  the  current 
in  the  solenoid  coil  to  decay  through  a "freewheeling"  diode.  When  the  current  in  the  solenoid  coil 
has  decayed  to  some  preset  level,  as  sensed  by  the  power  saver,  full  power  is  once  again  applied  to 
the  solenoid  coil.  The  averaging  of  these  two  preset  current  levels  produces  the  holding  power  level. 

The  power  saver  is  completely  solid-state;  thus,  the  unit  is  compact,  dependable,  and  durable. 

All  switching  operations  occur  without  inducing  line  voltage  spikes  from  coil  induction  and  without 
introducing  electromagnetic  interference  (EMI)  from  the  changing  current  rates.  The  switching  points 
for  actuation  and  holding  levels  are  absolute  values  and  are  not  affected  by  changes  in  line  voltage, 
ambient  temperature,  or  coil  warmup  temperatures.  The  power  saver  has  met  all  operating  parameters 
imposed  and  has  a rated  minimum  useful  life  of  20  000  hours. 


Valve-Position  Indicator 


Several  inherent  shortcomings  of  standard  mechanical  switches  has  led  to  the  development  of  the 
solid-state  valve-position  indicator.  This  position  indicator  employs  two  samarium-cobalt  magnets 
attached  to  the  valve  stem  and  a Hall-effect  transducer  to  accurately  indicate  the  relative  position 
(on/off)  of  a given  valve  within  a sealed  housing.  This  valye-position  sensing  technique  is  accom- 
plished without  penetration  of  the  valve  pressure  wall.  Mechanical  switches  require  a portion  of  the 
valve  stem  to  extend  through  the  pressure  wall.  Valve  stem  penetration  of  the  pressure  wall  neces- 
sitates additional  dynamic  seals  at  the  point  of  penetration  and  thus  increases  friction  and  poten- 
tial leakage  points.  In  the  case  of  the  valve-position  indicator,  a magnetic  flux,  developed  by  the 
samarium-cobalt  magnets,  passes  directly  through  the  pressure  wall  to  operate  the  Hall-effect  trans- 
ducer (fig.  5). 

The  new  valve-position  indicator  technique  results  in  a reduced  hysteresis  (differential  travel) 
distance.  Mechanical  switches  require  a minimum  of  0.010  inch  of  travel  between  the  on  and  off 
switching  positions.  The  magnet  and  Hall-type  transducer  combination  is  capable  of  discerning  move- 
ments as  small  as  0.003  inch.  This  value  is  less  than  one-third  previously  required  travels;  thus, 
lower  valve  flow  settings  are  obtainable. 
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FIGURE  5.-  SOLID-STATE  VALVE-POSITION  INDICATOR. 


The  absence  of  moving  parts  completely  eliminates  wear-related  failures  and  ensures  infinite 
cycle  life.  Mechanical  switches  are  subject  to  breakdown  due  to  excessive  flexing,  which  results  in 
deterioration  of  hermetic  seals.  Mechanical  switches  are  also  subject  to  contact  erosion  with 
resulting  increases  in  circuit  resistance;  additionally,  contact-point  bounce  produces  unwanted  EMI. 
The  output  signal  of  mechanical  switches  is  of  poor  quality  and  may  result  in  a sensitive  indicator 
or  recorder  producing  erroneous  data.  This  valve-position  indicator  is  free  of  these  mechanical  im- 
pairments and  consistently  produces  "clean"  signals  in  less  than  0.5  millisecond. 

Vibration  has  no  effect  on  the  valve-position  indicator.  The  sensing  element  (Hall-type 
transducer)  is  rigid  with  no  moving  parts,  and  the  magnets  are  rigidly  attached  to  the  valve  stem. 

A minimum  of  5 ounces  of  actuation  force  is  required  to  operate  the  most  sensitive  mechanical 
switches;  many  switches  require  10  to  20  ounces  actuation  force.  The  valve-position  indicator  re- 
quires only  4 ounces  of  force  to  operate.  Additionally,  no  preloading  of  the  valve  stem  and  no 
retention  force  is  required  to  maintain  the  Hall-type  transducer  in  the  actuated  position.  Since 
no  mechanical  linkage  is  made  with  the  switching  portion  arrangement  in  the  valve-position  indicator, 
overtravel  problems  are  nonexistent. 


Flow  Sensor 

Two  flow  sensors  are  used  in  each  of  two  redundant  systems  in  the  cabin  pressure  control  panel: 
one  for  oxygen  at  900  psi  and  the  other  for  nitrogen  at  200  psi.  Each  flow  sensor  is  calibrated  to 
read  mass  flow  rates  between  0 and  5.0  lb/hr  using  the  appropriate  gas  and  pressure.  Flow-rate  dis- 
plays are  provided  for  the  crew,  and  data  are  telemetered  to  monitoring  stations  on  Earth.  Caution 
and  warning  signals  alert  the  crew  if  flow  rates  exceed  4.9  Ib/hr. 

The  flow  sensor  consists  of  a relatively  large,  straight-through,  cylindrical  passage  with  sev- 
eral thicknesses  of  woven  stainless  steel  wire  filter  mesh  located  approximately  midway  across  the 
passage.  A parallel  flow  path  bypasses  the  filter  by  way  of  a capillary  tube  the  ends  of  which  are 
just  upstream  and  downstream  of  the  filter.  The  purpose  of  the  filter  is  to  produce  a pressure  drop 
across  the  ends  of  the  capillary  tube  and  thereby  to  induce  a small  flow  through  the  capillary  tube. 
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The  flow  sensed  is  flow  that  bypasses  the  main  stream  by  way  of  this  small -diameter  tube.  A layer  of 
thermally  conductive,  electrically  insulating  material  is  deposited  on  the  outside  of  the  capillary 
tube.  Two  separate  coils  of  very-small -diameter  resistance  wire  are  closely  wrapped,  one  after  the 
other,  around  the  capillary  tube.  Each  of  these  resistance  coils  is  one  leg  of  an  electrical  bridge. 

The  determination  of  flow  rate  is  based  on  the  difference  in  temperature  of  these  adjacent  resis- 
tors as  a result  of  flow.  The  resistance  of  the  wire  varies  with  the  wire  temperature  so  that  the 
bridge  bias  that  exists  at  zero  flow  is  upset.  The  degree  of  upset  is  sensed,  amplified,  temperature 
compensated,  and  linearized  to  compensate  for  nonlinear  pressure  differential  across  the  aforemen- 
tioned layers  of  filter  screen.  The  result  is  an  analog  voltage  output  that  varies  from  0 to  5 volts 
direct  current  as  the  mass  flow  rate  varies  from  0 to  5 Ib/hr. 

The  basic  design  approach  remained  the  same  during  development  and  qualification.  However,  sat- 
isfactory implementation  of  the  design  proved  troublesome.  In  retrospect,  the  solutions  seem  obvious. 
At  the  time,  each  anomaly  seemed  mysterious  and  required  careful  investigative  work.  One  frustrating 
example  was  originally  thought  to  be  a matter  of  test  equipment  and  test  procedure  differences  be- 
tween the  manufacturer  and  the  receiving  inspection.  Identical  test  masters  for  both  stations  were 
calibrated  at  the  same  time.  The  same  gage  facility  and  test  equipment  was  duplicated;  test  proce- 
dures were  standardized  to  no  avail.  Test  results  still  differed.  It  was  finally  discovered  that 
the  manufacturer,  to  assure  an  optimum  degree  of  cleanliness,  was  flushing  the  unit  with  cleaning 
fluid  after  his  acceptance  tests.  Unfortunately,  the  cleaning  fluid  used  was  badly  contaminated. 

This  in  turn  partly  clogged  the  internal  filters,  used  to  create  a controlled  pressure  differential, 
and  altered  the  heat-transfer  characteristic  of  the  flow-sensing  capillary  tube.  The  solution  was 
clean  fluid  and  the  addition  of  a finer  convoluted  wire  mesh  filter  at  the  unit  inlet. 

The  need  for  additional  diodes  was  revealed  by  EMI  tests.  Finding  space  for  the  diodes  and 
providing  mechanical  support  to  withstand  launch  vibration  required  additional  time  to  work  out  and 
prove. 

Another  problem  was  that  some  flow  sensor  elements  could  not  be  trimmed  and  adjusted  within  the 
range  of  the  electrical  elements  designed  to  accomplish  this  function.  The  defect  was  traced  to  a 
partial  breakdown  of  electrical  insulation  between  the  capillary  tube  and  the  wrap  of  resistance  wire 
around  the  tube.  Triple  electrical  insulation  coatings  are  now  used.  This  modification  resulted  in 
a reduction  of  flow  sensor  sensitivity  due  to  the  thermal  insulating  effects  of  the  electrical  insula- 
tion layers.  To  compensate,  the  electronics  components  were  changed  to  supply  more  power  so  that  the 
necessary  degree  of  sensitivity  could  be  returned. 

One  final  undesirable  characteristic  of  the  flow  sensor  remains.  Flow  rates  greater  than  5.0 
Ib/hr  are  not  displayed;  caution  and  warning  signals  occur  at  4.9  lb/hr.  As  the  flow  rate  increases, 
the  two  adjacent  legs  of  the  resistance  bridge,  wrapped  around  the  flow-sensing  capillary  tube,  move 
closer  to  each  other  in  temperature  and  resistance  because  the  limited  power  available  to  the  bridge 
is  overcome  by  the  increased  heat  dissipation  of  the  higher  flow  rate.  At  some  flow  rate,  the  dis- 
play starts  to  reverse  with  additional  flow-rate  increases  until  an  indication  approaching  zero  may 
be  shown. 


Oxygen  Partial-Pressure  Sensor 

The  oxygen  partial-pressure  ( pOo ) sensor  (refs.  1 and  2)  has  an  impressive  operational  record 
including  thousands  of  hours  of  flight  time  accumulated  during  the  NASA  Skylab  and  Apollo-Soyuz 
missions.  In  the  Shuttle,  the  sensor  performs  the  same  function  as  in  the  Skylab  application  - 
providing  the  control  signal  to  maintain  proper  oxygen  levels  in  the  two-gas  (O2/N2)  cabin  atmos- 
phere. The  oxygen  sensor  has  evolved  into  a device  suitable  wherever  continuous,  real-time  mon- 
itoring of  oxygen  is  critical  and  has  been  successfully  adapted  to  a wide  range  of  man-rated  envi- 
ronmental control  systems  in  addition  to  that  of  the  spacecraft  cabin  oxygen  monitor  described 
previously. 

The  sensor  is  a self-contained,  self-powered  electrochemical  cell,  which  generates  a millivolt 
signal  as  a function  of  the  O2  partial  pressure  in  the  environment  being  monitored.  The  millivolt 
signal  generated  automatically  compensates  for  temperature  and  is  compatible  with  end-item  telemetry 
and  instrumentation  systems.  The  sensor  uses  the  controlled  conversion  of  chemical  energy  to 
electrical  energy  to  provide  a direct  measure  of  oxygen  partial  pressure.  This  function  is  accom- 
plished by  immersing  a pair  of  electrodes,  as  shown  in  figure  6,  in  an  electrolyte  retained  within  a 
bladder  and  a gas-permeable  membrane. 

Oxygen  contained  in  the  atmosphere  to  which  the  sensor  is  exposed  permeates  the  membrane  to  the 
gold  sensing  electrode  serving  as  a catalyst  to  ionize  the  oxygen  molecule.  The  electrolyte,  an  alka- 
line solution,  provides  a conductive  path  for  ionized  O2  to  the  metal  counter  electrode  to  form  a 
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FIGURE  6.-  CUTAWAY  VIEW  OF  THE  OXYGEN  PRESSURE 
SENSOR. 


— t — 
| 

> 

fnl 

t 

D 

1 ©, 
1 RT1 ; 

\ Rp 

CELL  NETWORK 

FIGURE  7.-  SENSOR  SCHEMATIC. 


metal  oxide.  This  oxidization  involves  a release  of  electrons,  which  flow  through  an  external  resist- 
ance (fig.  7)  to  provide  the  sensor  output  signal. 

The  current/partial-pressure  relationship  is  constant  for  a specific  electrode  configuration  and 
constant  temperature.  For  changes  in  temperature,  the  absolute  permeability  of  the  membrane  varies 
and  thus  produces  a change  in  the  output  current.  The  change  in  permeability  (hence  current)  is  a 
first-order  change  increasing  logarithmically  with  increasing  temperature.  Dependence  on  temperature 
is  essentially  eliminated  from  the  sensor  output  signal  by  matching  the  cell  to  a resistive  load 
including  a temperature-sensiti ve  component  (fig.  7).  The  component,  a thermistor,  is  trimmed  with 
series  and  parallel  resistances  to  provide  a network  temperature  coefficient  which  is  equal  in 
magnitude  but  negative  with  respect  to  the  temperature  component  of  the  membrane  permeability. 

The  theoretical  sensor  life  is  readily  determined  by  electrochemical  relationships.  The  copper 
counter  electrode  is  the  consumable  and  is  depleted  at  a rate  which  is  related  directly  to  the  elec- 
trical current  generated  by  the  sensor.  Actual  life  of  a specific  sensor  will  vary  with  average 
operating  temperature  and  oxygen  partial  pressure  as  well  as  with  thickness  of  the  diffusion  barrier 
(membrane). 

Required  calibration  frequency  is  a function  of  system  accuracy  constraints  and  sensor  drift. 
Initial  calibration  upon  installation  will  hold  for  the  life  of  the  sensor.  Results  of  recently 
completed  tests  indicate  average  sensor  drift  during  operation  to  be  -0.23  mmHg  pO^  per  month.  When 
compared  to  the  Shuttle  oxygen  monitor  accuracy  requirement  of  +7.75  mmHg  pOo,  it  is  clear  that  an 
initial  calibration  should  hold.  Required  operating  life  is  6236  hours  at  297  K and  165  mmHg  pOp. 

The  sensor  is  not  affected  by  background  gases  normally  found  in  a habitable  atmosphere.  A 
shift  in  calibration  with  total  pressure  would  therefore  be  attributed  to  a physical  change  within 
the  sensor,  specifically  to  a change  between  the  diffusion  barrier  and  the  sensing  electrode.  A 
shift  of  this  nature  is  prevented  by  (1)  the  flexible  bladder  referenced  to  sample  pressure  and 
(2)  the  front-end  design  for  which  a unique  process  has  been  developed  to  integrate  the  membrane 
and  sensing  electrode  into  a stable  one-piece  assembly. 

Sensor  response  rate  is  a function  of  temperature,  film  thickness,  and  thickness  of  the  gold- 
plate  applied  to  the  sensing  electrode.  Film  and  goldplate  thickness  have  evolved  to  satisfy  the 
maximum  number  of  applications  and  to  idealize  overall  performance.  Rate  of  output  response  for 
the  standard  sensor  at  298  K is  to  within  90  percent  of  a step  change  in  pOp  in  30  seconds  or 
less. 


Early  sensor  configurations  employed  a stainless  steel  rigimesh  substrate  sensing  electrode.  A 
gold-plated,  sintered  nickel  sensing  electrode  was  substituted  to  enhance  performance,  through 
greater  active  surface  area,  and  to  eliminate  sensitivity  drift  during  storage.  Additionally,  the 
sintered  nickel  disk  provides  a more  uniform  sealing  surface  and  an  increased  film  support  area  and 
permits  spotwelding  of  leads.  Newer  sensor  configurations  also  employ  a gain  adjustment  within  the 
amplifier  portion  of  the  transducer  to  facilitate  field  adjustment.  This  gain  adjustment  replaces 
the  previous  method  of  individually  adjusting  the  potentiometers  within  the  sensor  and  eliminates  the 
possibility  of  unbalancing  the  sensor  temperature  compensation  circuit. 
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Cabin  Pressure  Regulator 


The  cabin  pressure  regulators  and  the  oxygen  partial -pressure  sensors  together  maintain  the  crew 
compartment  atmosphere  at  14.7  ± 0.2  psia  total  pressure  and  3.20  ± 0.25  psia  oxygen  partial  pres- 
sure (ref.  3).  The  function  and  accuracy  of  the  oxygen  partial -pressure  sensors  are  unaffected  by  vi- 
bration, acceleration,  and  shock  once  their  elements  are  adequately  supported  to  withstand  the  re- 
sultant dynamically  induced  stresses.  However,  cabin  pressure  regulators  depend  on  the  positional 
interaction  of  internal  mechanical  elements.  Close-tolerance  pressure  regulation  required,  ±1.36 
percent,  necessitates  a design  sensitive  both  to  the  crew  compartment  pressure  feedback  control  and 
to  the  externally  imposed  dynamic  environment. 

Qualification  testing  showed  the  14.7-psia  pressure  regulators  to  be  sensitive  to  the  random 
vibration  spectrum  of  the  Shuttle  launch  environment.  The  level  of  regulation  exceeded  Shuttle  speci- 
fication limits  during  launch  vibration.  Since  their  operation  during  launch  is  unnecessary,  this  de- 
viation might  have  been  countered  by  closing  the  unit's  manual  on-off  valves  before  launch  and  opening 
them  when  in  orbit.  However,  two  other  problems  occurred  as  a result  of  100-mission  random  vibration 
testing:  (1)  after  vibration,  the  pressure  regulation  level  decreased  as  much  as  0.25  psi  and  (2)  in- 

ternal leakage  increased  greatly.  Short  vibration  time  qualified  the  ARPCS  Np/O?  control  panel  for 
use  on  the  first  Shuttle  development  flights.  Nevertheless,  extending  the  vibration  duration  to 
encompass  100-mission-life  simulation  showed  that  the  cabin  pressure  regulator  performance  degraded 
sufficiently  to  require  further  corrective  action. 

The  control  pressure  sensed  by  the  cabin  pressure  regulators  during  launch  is  only  a little 
higher  than  the  14.7  psia  that  they  are  set  to  control.  This  means  that  the  springs  and  the 
pressure-sensing  device  are  practically  in  balance  so  that  any  disturbing  force,  such  as  imposed 
vibration,  causes  these  internal  elements  to  react  rather  violently.  The  movement  thus  induced 
causes  accelerated  wear.  Damage  to  the  pressure  regulator  seats  caused  excessive  internal  leakage 
and  pressure  regulation  shifts.  The  most  effective  and  uncomplicated  way  to  immobilize  the  unit 
internally  was  to  close  the  port  where  the  regulator  senses  the  crew  compartment  pressure  and,  at 
the  same  time,  raise  the  pressure  that  the  regulator  sensing  element  sensed  internally.  This 
raised  pressure  must  be  high  enough  to  force  the  metal  bellows  pressure-sensing  element  back  a- 
gainst  its  internal  parts  to  achieve  the  desired  results.  The  source  selected  to  backpressurize 
the  cabin  regulators  was  the  nitrogen  regulator  normally  used  to  pressurize  the  water  tanks. 


The  cabin  pressure  regulators  already  had  manual  toggle-operated  on-off  valves.  The  cabin  pres- 
sure regulators  were  redesigned  in  such  a way  that  a single  action  of  the  toggle  could  accomplish  the 
required  functions  simultaneously.  The  resultant  multifunction  toggle  valve  is  a two-position,  five- 
way valve.  Two  poppet/seat  combinations  have  been  added  to  accomplish  the  desired  backpressure  func- 
tion. Nitrogen  from  the  16-ps 1 g water  pressurization  regulator  is  fed  to  the  appropriate  port  of 
the  designed  valve  to  act  as  the  backpressure  source.  Reversing  the  toggle  position  closes  the  pop- 
pets that  were  open  and  opens  those  that  were  closed  so  that  normal  crew  compartment  pressure  control 
can  resume. 
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ABSTRACT 


In  designing  work  stations  and  restraint  systems,  and  in  planning  tasks  to  be  performed  in 
space,  a knowledge  of  the  capabilities  of  the  operator  is  essential.  Answers  to  such  questions  as 
whether  a specific  control  or  work  surface  can  be  reached  from  a given  restraint  and  how  much  force 
can  be  applied  are  of  particular  interest.  A computer-aided  design  system  has  been  developed  for  de- 
signing and  evaluating  work  stations,  etc.,  and  the  Anthropometric  Measurement  Laboratory  (AML)  has 
been  charged  with  obtaining  the  data  to  be  used  in  design  and  modeling. 

Traditional  methods  of  measuring  reach  and  force  are  very  labor  intensive  and  require  bulky 
equipment.  The  AML  has  developed  a series  of  electro-optical  devices  for  collecting  reach  data  eas- 
ily, in  computer  readable  form,  with  portable  systems.  The  systems  developed,  their  use,  and  data 
collected  with  them  are  described. 


INTRODUCTION 


THE  CHALLENGE 

The  Space  Shuttle  program  brought  a challenge  to  spacecraft  designers  to  accommodate  comfortably 
and  efficiently  a much  larger  portion  of  the  population  than  had  been  considered  previously.  The 
Shuttle  was  to  be  operated  by  persons  ranging  in  size  from  the  fifth  percentile  female  to  the  ninety- 
fifth  percentile  male,  a range  of  approximately  a foot  in  height. 

Providing  suitable  work  stations  and  living  quarters  for  humans  operating  in  a zero-g  environment 
requires  consideration  of  many  new  phenomena  (refs.  1 to  3).  For  example,  the  body  changes  in 
size  and  shape:  the  torso  stretches  as  much  as  2 inches  and  the  waist  may  shrink  a similar  amount. 

The  natural  comfortable  posture  in  space  is  very  different  from  the  normal  posture  on  Earth.  Spe- 
cifically, the  legs  and  arms  bend  forward  from  the  torso  rather  than  hanging  straight  down;  they 
are  flexed  at  the  elbows  and  knees.  The  head  tilts  downward,  lowering  the  line  of  sight.  In  order 
to  produce  any  effective  force,  the  astronauts  must  be  restrained  in  some  way  or  they  will  simply 
move  themselves. 

To  develop  work  stations,  plan  tasks,  and  design  habitable  areas,  quantitative  data  are  required 
on  the  anthropometric  characteristics  of  users  in  zero  g.  These  data  can  be  collected  in  various 
ways:  measurements  may  be  taken  in  one  g and  extrapolated  to  zero-g  conditions;  they  may  be  taken  in 

simulated  zero  g,  as  in  the  Weightless  Environment  Training  Facility;  or  they  can  be  determined  from 
data  collected  on  Skylab  or  the  Shuttle.  No  matter  how  the  data  are  obtained,  they  should  be  made 
available  to  designers  in  the  early  stages  of  the  design  process. 

Specific  measurements  desired  are  the  sizes  of  body  components  (height,  arm  length,  leg  length, 
chest  circumference,  etc.),  the  reach  capabilities,  the  strength  that  may  be  applied  at  various  posi- 
tions, and  the  time  it  takes  to  perform  a given  motion. 


THE  APPROACH 

The  approach  to  this  challenge  has  been  to  build  an  Operator  Station  Design  System  which  in- 
cludes a computer-aided  design  (CAD)  system  and  the  Anthropometric  Measurement  Laboratory.  The 
development  of  PLAID  (Panel  Layout  Automated  Interactive  Design),  the  CAD  system,  started  in  1976 
(ref.  4).  At  the  same  time,  development  of  automated  equipment  to  collect  anthropometric  data 
was  begun  (ref.  5).  The  emphasis  has  been  to  use  computer  technology,  from  a VAX  11/780  computer 
to  a Rockwell  6502  microprocessor,  to  collect  data,  process  the  data,  present  data  to  the  design 
engineers,  and  provide  design  tools  for  the  engineers.  The  goal,  not  yet  achieved,  is  to  provide 
dynamic  models  of  human  activities  in  candidate  work  areas  and  habitations.  These  models  would 
ideally  take  a task  description  or  checklist,  translate  it  Into  desired  movements,  simulate  those 
movements  for  bodies  described  in  the  anthropometric  data  base,  and  report  to  the  engineer  on  such 
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issues  as  inability  to  reach  items,  collision  with  other  bodies  or  with  spacecraft  furnishings, 
the  time  to  perform  the  actions,  the  strength  required,  and  other  design  concerns. 


BACKGROUND 


ANTHROPOMETRIC  MEASUREMENT  SYSTEM 

The  first  step  in  developing  an  automated  anthropometric  measurement  system  for  range  of  motion 
data  was  the  design  and  development  of  a video-based  system  for  joint  angle  measurements.  This  de- 
vice, called  a goniometer,  and  the  subsequent  anthropometric  measurement  systems  were  developed  by 
Southwest  Research  Institute  of  San  Antonio,  Texas,  under  the  guidance  of  Dr.  W.  E.  Thornton  of  the 
JSC  Astronaut  Office  (ref.  6).  To  measure  joint  range  of  motion,  a bar  with  incandescent  bulbs  on 
each  end  is  attached  to  the  limb  to  be  moved.  The  limb  is  positioned  in  a neutral,  0°  position.  The 
two  lights  are  alternately  blinked  on  and  off  several  times  under  microprocessor  control.  The  posi- 
tion of  the  lights  is  sensed  through  a video  camera  and  a line  is  fitted  to  the  two  points  by  the 
microprocessor.  The  limb  is  then  moved  to  an  extreme  position,  the  lights  are  activated,  a second 
line  is  fitted,  and  the  angle  between  the  lines  is  displayed  on  a digital  readout. 

The  goniometer  was  a first  step,  a feasibility  test,  of  the  possibility  of  measuring  motion 
through  video  tracking  of  point  sources  of  light.  The  goniometer  was  a two-dimensional  device:  the 

person  being  measured  had  to  sit  or  stand  so  that  the  axis  of  rotation  was  perpendicular  to  the  cam- 
era image  plane.  The  total  errors  achieved  during  testing  did  not  exceed  +4°  at  a distance  of  8 
feet  from  the  camera;  the  average  error  was  about  2°. 

The  next  step  was  the  development  of  a three-dimensional  tracking  system.  This  anthropometric 
measurement  system  (AMS)  locates  positions  in  three  dimensions  by  tri angul ation.  Three  video  cameras 
are  positioned  on  three  corners  of  a rectangle.  Two  small  incandescent  bulbs,  which  are  to  be  tracked, 
are  attached  to  the  person,  for  example,  on  the  fingertips  for  collecting  reach  data.  Figure  1 illus- 
trates the  arrangement  of  cameras,  equipment,  and  subject.  The  room  is  very  dimly  illuminated.  A 


FIGURE  1.-  THREE  CAMERAS  ARE  USED  TO  TRACK  A LIGHT  ON  THE  CREWMEMBER'S  HAND. 
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microprocessor  turns. on  one  light,  analyzes  a video  scan  for  the  peak  brightness,  digitally  records 
its  position  in  the  video  image  plane,  then  sequentially  analyzes  the  video  scans  from  the  other  two 
cameras  in  the  same  manner.  If  no  signal  rises  above  a preset  threshold  value,  a "no  data"  flag  is 
stored  for  that  camera,  for  that  scan.  The  first  light  is  then  turned  off,  the  second  lit,  and  the 
process  proceeds.  Because  of  the  video  processing  and  the  inherent  limitations  of  incandescent  bulb 
cycling,  the  data  rate  is  about  10  points  per  second. 

The  digital  data  are  stored  on  a floppy  disk  during  the  test.  Data  analysis  is  performed  after 
the  test.  The  position  of  a point  in  three-dimensional  space  is  determined  from  the  camera  coordi- 
nates (two  dimensions)  from  two  non-colinear  cameras.  With  three  cameras,  180°  coverage  is  possible. 

The  AMS  also  has  provisions  for  force  data  collection.  A commercially  available  Cybex 
dynamometer  with  a special  pulley  arrangement  is  connected  to  the  AMS  so  that  force  is  digitally 
recorded  with  corresponding  position  data. 

Development  of  PLAID  began  in  1976  (ref.  7).  This  project  was  intended  to  provide  a powerful 
design  tool  for  spacecraft  design  engineers.  Standard  CAD  features  in  PLAID  include  composition 
of  primitive  objects  to  form  complex  assemblies,  data  entry  through  cursor,  digitizer,  or  keyboard, 
display  in  wireframe  or  with  hidden  line  removal,  and  viewpoint  position  and  orientation  specified 
by  user.  This  capability  was  developed  for  JSC  by  Rothe  Development,  Inc.,  of  San  Antonio,  Texas, 
with  the  guidance  of  J.  L.  Lewis,  J.  W.  Brown,  and  M.  M.  Thomas  of  the  Engineering  and  Development 
Directorate  of  JSC. 

The  extensive  use  of  PLAID  in  Shuttle  operations  planning  has  been  reported  by  J.  W.  Brown 
(ref.  8).  The  conflict  detection  algorithms  permit  fit  checks  to  be  made  early  in  the  design 
process  rather  than  in  mockups.  Through  viewpoint  specification,  the  areas  in  sunlight  or  earth- 
shine  can  be  displayed  by  specifying  the  viewpoint  to  be  at  the  Sun  or  the  Earth.  A variable  lens 
focal  length  feature  allows  assessment  of  camera  fields  of  view.  Previously,  all  of  these  tests 
had  to  be  conducted  with  models  and  mockups,  with  a high  cost  in  materials  and  manpower. 

The  initial  human  modeling  capabilities  of  PLAID  were  limited.  Bodies  had  to  be  constructed 
in  pieces  and  assembled  into  the  desired  position  by  specifying  the  angle  of  each  limb  to  another 
body  part.  Digitized  data  describing  one  human  body  in  detail  were  obtained  from  the  Institute 
for  Biomedical  Engineering  Research  at  the  University  of  Akron. 

An  early  feature  of  the  system  was  the  REACH  module,  which  provided  for  the  use  of  data  col- 
lected with  the  AMS.  The  AMS  data  consisted  of  a collection  of  points  in  three-dimensional  space 
indicating  those  areas  which  the  subject  could  reach.  Figure  2(a)  is  an  elapsed  time  photograph 
taken  during  the  collection  of  reach  data  in  a pressurized  suit.  To  make  use  of  this,  provisions 
exist  for  examining  one  horizontal  (or  vertical)  "slice"  of  some  given  thickness  and  drawing  closed 
contours  enclosing  the  points.  Figure  2(b)  shows  a "slice"  of  reach  points  with  the  boundaries 
drawn  in.  The  contours  could  be  smoothed,  and  the  sequential  contours  joined  together  to  form  a 
three-dimensional  solid  object.  This  process  is  illustrated  in  figure  2(c).  The  resulting  object 
could  then  be  positioned  by  PLAID,  and  its  intersection  with  such  elements  as  work  stations,  controls, 
and  surfaces  to  be  reached  displayed.  This  capability  was  used  extensively  in  analysis  of  thermal 
protection  system  repairs  before  the  STS-1  mission.  Figure  2(d)  shows  the  model  of  an  astronaut 
with  reach  envelope  attached  for  use  in  evaluating  reach  capabilities. 


THE  EVOLUTION 

The  limitations  of  the  AMS  prototype  were  the  data  rate,  the  number  of  points  tracked,  and 
the  requirement  for  low  light  levels.  A high-speed  AMS  (HAMS)  was  developed  to  surmount  these  dif- 
ficulties (ref.  9).  The  HAMS  is  based  on  the  corrmercially  available  SELSPOT  system,  which  permits 
tracking  up  to  30  separate  points  at  rates  up  to  300  hertz.  The  SELSPOT  used  infrared  emitting 
diodes  (IRED's)  to  provide  the  fast  switching  rates  and  to  provide  a signal  in  a radiation  wave- 
length not  strongly  generated  by  normal  room  lighting.  The  light  detection  is  done  by  a photo- 
sensitive plate  which  generates  currents  in  its  "x"  and  "y"  axes  in  proportion  to  the  location 
of  the  center  of  intensity.  The  image  is  focused  on  the  plate  by  Canon  lenses.  The  output  con- 
sists of  two  analog  signals  (x,  y position)  which  are  digitized  and  initially  processed  by  the 
SELSPOT  control  hardware. 

The  SELSPOT  system  was  originally  designed  to  feed  raw  data  into  a computer  at  high  rates. 

To  provide  portability,  the  unit  was  coupled  with  a microprocessor-controlled  recording  and  play- 
back unit  in  its  implementation  at  JSC.  The  resulting  system  can  be  loaded  on  a laboratory  cart 
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(a)  DATA  ARE  COLLECTED  FOR  REACH  RANGE 
IN  A PRESSURIZED  SUIT. 


(b)  REACH  DATA  ARE  PLOTTED,  AND  CONTOURS  INDI- 
CATING THE  REACH  RANGE  ARE  DRAWN  BY  THE  INVESTI- 
GATOR. 


(d)  A PLAID  RECONDITION  OF  A SUITED  CREWMEMBER 
WITH  THE  TWO-HANDED  REACH  ENVELOPE  ATTACHED  FOR 
INSPECTION. 


FIGURE  2.-  STEPS  FOR  COLLECTING  REACH  DATA. 
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and  transported  to  any  desired  location  to  collect  data.  After  the  test,  the  system  is  transported 
to  the  computer  room  to  dump  the  raw  digital  data  to  computers  for  processing.  The  interface  to 
PLAID  through  REACH  is  maintained. 

This  system  has  been  used  to  collect  range  of  motion  data  for  use  in  evaluating  alternate  joint 
designs  for  an  8-psi  space  suit.  Besides  its  use  for  collecting  reach  data,  it  has  been  used  to  re- 
place the  goniometer  and  generates  images  of  the  arcs  swung  by  a distal  limb  when  a joint  is  rotated. 
Figure  3 shows  arcs  from  two  different  suit  designs  generated  by  movement  of  the  shoulder  joint. 


§ 


f 





* 


FIGURE  3.-  SHOULDER  ROTATION  ARCS  IN  TWO  PROTOTYPE  SUITS.  IRED’S  WERE  ATTACHED  TO 

THE  UPPER  ARM  AND  ELBOW. 


PLAID  is  undergoing  development  in  two  directions.  The  graphics  capabilities  are  being  extended, 
and  the  man  modeling  capabilities  are  being  increased.  Additions  to  the  graphics  include  generation 
of  raster  output,  the  use  of  color  and  shadowing,  and  the  use  of  hardware  and  firmware  implementations 
of  hidden  line  removal  to  increase  the  speed  of  the  output  by  orders  of  magnitude. 

Man  modeling  has  been  an  active  research  area  in  computer  science.  One  model,  "Bubbleman,"  de- 
veloped by  Dr.  Norman  1.  Badler  and  his  colleagues  (refs.  10  and  11),  is  being  integrated  with  PLAID 
and  the  model  extended  significantly.  Figure  4 shows  a typical  "Bubbleman"  standing  up.  Special 
features  of  this  model  include  the  ability  to  select  or  build  a body  by  specifying  a few  parameters 
rather  than  generating  complex  solids,  and  the  ability  to  position  a body  by  specifying  a few  key 
points  rather  than  every  angle  and  distance.  The  current  model  is  a kinematic  model.  When  given 
a starting  position  and  a desired  ending  position,  the  model  can  generate  the  intermediate  steps 
necessary  to  transition  from  one  to  the  other.  This  animation  technique  provides  a very  helpful 
tool  for  the  design  engineer  in  checking  reachability  for  detecting  possible  collisions  between 
one  body  and  another  or  between  a body  and  surrounding  crew  station  surfaces. 
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FIGURE  4.-  BUBBLEMAN  IN  A STANDING  POSITION. 


CURRENT  PLANS 


SURFACE  MAPPING 

Further  developments  of  the  anthropometric  measurement  system  and  of  PLAID  are  planned. 

The  next  stage  of  the  Anthropometri c Measurement  Laboratory  is  to  develop  a technique  for 
mapping  the  entire  body  surface.  Current  techniques  for  obtaining  a digital  representation  of 
the  surface  of  a human  body  are  based  on  manually  picking  points  from  stereophotographs.  This 
is  an  error-prone  and  laborious  method.  In  conjunction  with  Wright  Patterson  Air  Force  Base  (WPAFB), 
a laser-based  anthropometri c measurement  system  (LAMS)  is  being  designed  and  built.  The  principal  in- 
vestigator is  Dr.  Bruce  R.  Altschuler  of  WPAFB.  The  design  of  this  system  is  described  by  M. 
Altschuler  (refs.  12,  13,  and  14). 

The  principle  involved  is  again  tri angul ation.  In  this  application,  rather  than  having  data 
from  two  video  cameras  or  two  electo-opti cal  devices,  there  is  an  "active"  camera  and  a "passive"  cam- 
era. The  passive  camera  is  indeed  a sensitive  video  camera.  The  "active"  camera  is  a rectangular 
array  of  discrete  beams  of  light  which  are  projected  on  the  object  to  be  measured.  Multiple  expo- 
sures are  used  to  give  a position  code  for  each  beam  position.  Figure  5 shows  the  beam  array  pro- 
jected on  a model  spaceman.  There  are  128  columns  of  beams;  in  this  exposure,  every  other  8 columns 
are  blanked  out.  Thus,  for  an  array  of  128  by  128  beams  (more  than  16  000  points),  there  must  be  a 
minimum  of  8 exposures  (log2N  + 1)  to  permit  a binary  coding  of  the  location  of  the  column  from  which 
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the  beam  originates.  Each  exposure  currently  takes  one-thirtieth  of  a second,  because  of  the  limit- 
ing factor  of  video  scan  rate.  Thus,  to  obtain  eight  exposures  requires  approximately  one-third  of 
a second.  This  is  adequate  for  cooperative,  stationary  objects  but  is  limiting  for  collection  of 
velocity  data. 


FIGURE  5.-  BEAM  ARRAYS  PROJECTED  ON  MODEL  ASTRONAUT.  THERE  ARE  128  COLUMNS  OF  BEAMS.- 
IN  THIS  PICTURE,  THE  PATTERN  IS  8 COLUMNS  OFF,  8 COLUMNS  ON. 


The  design  goal  is  to  be  able  to  collect  all  necessary  exposures  within  100  milliseconds 
or  less,  to  permit  mapping  motion  data  for  kinematic  and  dynamic  models.  Two  items  are  currently 
limiting:  the  light  modulator  and  the  camera.  There  are  several  technical  challenges  in  developing 

a surface  mapping  system.  One  is  development  of  an  adequately  fast  "shutter,"  which  is  actually 
not  a mechanical  shutter  but  a light  modulator  whose  transparency  or  opacity  is  determined  by 
an  electric  current.  The  first-generation  light  modulator  was  developed  by  Sandia  Laboratory; 
a second-generation  one  with  lower  power  requirements  and  higher  speed  is  under  development. 

Design  of  a CCD  camera  with  parallel  outputs  to  cut  data  acquisition  time  from  one-thirtieth  of 
a second  to  milliseconds  is  proposed.  The  multiple-exposure  beam  position  coding  technique,  the 
implied  algorithm  for  decoding  the  beam  position,  and  the  calibration  procedures  in  which  calibration 
is  performed  by  viewing  an  object  of  known  size  and  shape  are  technical  problems  under  Investigation. 

The  applications  for  this  device  are  varied.  The  project  was  initiated  to  map  the  surfaces  of 
teeth  for  automatic  crown  development.  NASA  applications  require  a system  which  can  be  used  (1)  to 
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map  large  objects  at  long  ranges,  such  as  antennas;  (2)  to  map  human-sized  objects  at  medium  ranges 
to  collect  motion  data;  and  (3)  to  map  smaller  objects,  such  as  limbs  or  torso  to  determine  physi- 
ological changes  caused  by  fluid  shifting  and  other  zero-g  effects. 


DYNAMIC  MODELING 

The  ultimate  goal  of  the  Operator  Station  Design  System  is  to  permit  simulation  of  individual 
crewmembers  or  of  statistical  samples  from  a specified  population  performing  complex  tasks.  The  simu- 
lation would  model  the  motions  and  the  information  processing  that  takes  place  and  would  report  impos- 
sible or  very  difficult  actions,  percentage  of  population  capable  of  performing  an  action,  times  of 
performance,  and  a measure  of  workload  or  fatigue. 

The  immediate  goal  is  to  add  enhanced  graphics,  motion  models,  and  strength  models.  Graphic 
enhancements  include  modeling  reflectance  properties,  modeling  multiple  light  sources,  and  increasing 
the  speed  of  the  system.  The  strength  and  motion  models  will  drive  the  graphics  displays  to  show  how 
a specific  point  might  be  reached  (translation,  rotation,  limb  movements,  etc.)  and  how  much  force 
can  be  brought  to  bear  on  the  object  of  the  task. 


CONCLUSIONS 


Computerized  models  and  data  collection  techniques  provide  a means  of  placing  man  in  the  loop 
early  in  a design  cycle,  saving  time  and  money  over  the  techniques  which  rely  on  mockups.  With  the 
extensive  data  base  now  built  that  describes  the  Shuttle,  payloads,  and  workstations,  and  with  the 
anthropometric  data  base,  operations  can  be  planned  and  examined  for  fit,  visual  access,  and  physical 
access  without  recourse  to  mockups.  Further  automation  of  this  process  is  under  development. 
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ABSTRACT 


The  development  of  the  Shuttle  extravehicular  mobility  unit  (EMU)  has  required  significant  tech- 
nology advances  in  the  design  of  the  astronaut  life  support  system  and  space-suit  assembly.  For  the 
first  time  in  U.S.  manned  space  flight,  the  life  support  system  and  space-suit  assemblies  are  inte- 
grated into  a single  system  and  optimized  for  the  primary  function  of  supporting  astronaut  extravehic- 
ular operations.  Rather  than  accommodating  a limited,  male-only  astronaut  population,  the  EMU  must 
satisfy  size  requirements  for  both  males  and  females  with  a minimum  of  sized  parts.  In  addition,  the 
Shuttle  EMU  has  been  designed  to  implement  Space  Shuttle  Program  philosophy  of  long  operating  life  and 
mission  reuse  capability  to  minimize  program  lifetime  cost. 


INTRODUCTION 

The  advancement  in  life  support  system  and  space-suit  technology  achieved  by  the  development  of 
the  Shuttle  extravehicular  mobility  unit  (EMU)  shown  in  figure  1 is  best  illustrated  by  comparison 
with  the  requirements  for  and  the  design  features  of  the  Apollo  EMU  shown  in  figures  2 and  3.  This 
comparison  is  relevant  because  of  the  excellent  performance  of  the  Apollo  EMU  demonstrated  during  162 
man-hours  of  astronaut  lunar  surface  exploration  and  scientific  task  accomplishments.  The  same  basic 
Apollo  EMU  space-suit  design  was  again  successfully  demonstrated  during  the  Skylab  Program,  when  an 
additional  81  man-hours  of  astronaut  extravehicular  activity  (EVA)  tasks  were  performed. 
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FIGURE  1.-  SHUTTLE  EMU  COMPONENTS. 
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SHUTTLE 


APOLLO 


SHUTTLE 


APOLLO 


• NO  SUIT  REQUIREMENT  FOR  ORBITER  LIFE 
SUPPORT  SYSTEM  COMPATIBILITY  FOR  LOSS  OF 
SPACECRAFT  CABIN  PRESSURE 

• LIFE  SUPPORT  SYSTEM  INCLUDING  DISPLAYS 
AND  CONTROLS  MODULE  INTEGRATED  WITH 
SUIT  PRIOR  TO  LAUNCH 

• INCREASED  UPPER  TORSO  MOBILITY 

• CONSTRAINED  FRONT-TO-BACK  DIMENSION 
FOR  ORBITER  INTERDECK  HATCH 
PAS8THROUGH 

• NO  REQUIREMENT  FOR  ONE-SIXTH-G  LOWER 
TORSO  WALKING  MOBILITY 

• OPERATION  FROM  14.7  PSIA  TO  VACUUM 

• ZERO-G  ENVIRONMENT  USE  AND  RECHARGE 
COMPATIBILITY 


• MULTIPLE  MISSION  AND  ASTRONAUT  REUSE 


• 5TH  TO  95TH  PERCENTILE  FEMALE  AND  MALE 
STANDARD  SIZES 

• ZERO-G  BODY  GROWTH  SIZING  PROVISION 


• ENHANCEMENT  OF  MAINTAINABILITY 

• OPERATING  LIFETIME  OF  6 YEARS  FOR  SOFT 
GOODS  AND  15  YEARS  FOR  HARDWARE 


• COMMAND  MODULE  AND  LUNAR  MODULE  LIFE 
SUPPORT  SYSTEM  COMPATIBILITY  FOR  LOSS 
OF  SPACECRAFT  CABIN  PRESSURE 

• PORTABLE  LIFE  SUPPORT  SYSTEM  AND 
REMOTE  CONTROLS  UNIT  ATTACHED  INFLIGHT 
AFTER  SUIT  WAS  DONNED 

• BASELINE  FOR  SHUTTLE  COMPARISON 

• NO  SPECIFIC  CONSTRAINT  ON  SIZE 


• ONE-SIXTH-G  LUNAR  SURFACE  LOWER  TORSO 
WALKING  MOBILITY 

• OPERATION  FROM  5 PSIA  TO  VACUUM 

• BOTH  ONE-SIXTH  AND  ZERO-G  ENVIRONMENT 
USE  COMPATIBILITY  AND  ONLY  ONE-SIXTH-G 
RECHARGE  CAPABILITY 

• SINGLE  MISSION  AND  INDIVIDUAL  ASTRONAUT 
USE  ONLY 

• MALE  CUSTOM  SIZES  ONLY 


• NO  REQUIREMENT  - ZERO-G  BODY  GROWTH 
IDENTIFIED  DURING  SKYLAB  PROGRAM 

• BASELINE  FOR  COMPARISON 

• OPERATING  LIFETIME  OF  4 YEARS 


• HARD  FIBERGLASS  UPPER  TORSO  STRUCTURE 
WITH  INTEGRAL  LSS/DCM  BOLT-ON 
ATTACHMENT.  COOLING  WATER  A NO  VENT 
GAS  DUCTING,  AND  ELECTRICAL  HARNESS 
ROUTING 

• GIMBALED  SHOULDER  JOINT  WITH  SCYE 
BEARING  TO  INCREASE  UPPER  ARM  MOBILITY; 
WAIST  BEARING  TO  PROVIDE  UPPER  TORSO 
ROTATION  CAPABILITY  WITH  ASTRONAUT  IN 
EV  FOOT  RESTRAINTS 

• DENSE  LSS  PACKAGING  • 80%  DENSITY 

• FLANGE  MOUNTING  OF  LSS  TO  SUIT 


• LSS  OPTIMIZED  TO  LIMIT  EMU  FRONT-TO-BACK 
DIMENSION  TO  1S-3/4  IN. 

• AUTOMATIC  ACTIVATION  OF  EMERGENCY 
OXYGEN  SYSTEM 

• SINGLE  UMBILICAL  CONNECTION  FOR  LSS 
RESERVICE 

• INTERGRAL  MOTOR-DRIVEN  LSS  WATER  PUMP. 
FAN.  AND  WATER  SEPARATOR  ASSEMBLY 


• SUBLIMATOR  PROVIDES  FOR  UMBILICAL  IVA 
OR  EVA  OPERATION  BY  USING  CHILLED  WATER 
FOR  COOLING  VENTILATING  GAS  AS  WELL  AS 
HEAT  TRANSPORT  WATER  LOOP 

• ASTRONAUT  PROVIDED  WITH  SYSTEM 
PERFORMANCE  STATUS.  INCLUDING 
EXPENDABLES,  WARNINGS.  AND  CORRECTIVE 
ACTION  PROCEDURES 

• SUIT  REDUNDANT  AXIAL  LOAD  RESTRAINTS 
FOR  ALL  FABRIC  PRESSURE  RESTRAINT 
ELEMENTS 

• SUIT  SIZING  COMPONENTS  MODULARITY  WITH 
FLANGE-MOUNTED  FABRIC  PRESSURE 
RESTRAINT  AND  BLADDER  HARDWARE 
ATTACHMENT.  SEPARABLE  SIZED 
COMPONENTS  INCLUDE  UPPER  ARMS.  LOWER 
ARMS.  GLOVES.  WAIST.  LEG  SECTION.  AND 
BOOTS 

• LOW  ENDURANCE  AND  AGE  LIFE  APOLLO 
COMPONENTS  ELIMINATED: 

• METAL  DISCONNECT  ENTRY  CLOSURE 


FIGURE  2.-  SIGNIFICANT  REQUIREMENT  DIFFERENCES  BE- 
TWEEN SHUTTLE  AND  APOLLO  EMU'S. 


• FABRIC  WEBBING  WITH  METAL  ATTACHMENT 
BRACKETS  FOR  AXIAL  RESTRAINT  LOADS 

• POLYURETHANE-COATED  NYLON  BLADDER 
FABRICS 

• REDUCED  COST  SUIT  MANUFACTURING 
PROCESSES: 

• HEAT-SEALED  BLAODER  SEAMS 


• FLAT  PATTERNED  FABRIC  JOINT  ELEMENTS 

• MULTIPLE  LAYER  SEWN-THROUGH  SEAMS 
FOR  THERMAL  MICROMETEOROIO  GARMENT 
INSULATION 


• SOFT  FABRIC  TORSO  WITH  BRACKET8  FOR 
PLSS/RCU  HARNESS  STRAP  ATTACHMENT; 
SEPARATE  INTERNAL  COOLING  WATER  AND 
VENT  GAS  DUCTING;  AND  MULTIPLE  GAS. 
WATER.  AND  ELECTRICAL  CONNECTORS 

• CABLE  RESTRAINED  SHOULDER  CONVOLUTE 
JOINT  FOR  UPPER  ARM  MOBILITY, 
CABLE/PULLEY  RESTRAINED  WAIST  AND  HIP 
CONVOLUTES  FOR  WALKING  CAPABILITY 


• RELAXED  LSS  PACKAGING  - 40%  DENSITY 

• STRAPS,  HOSES,  AND  ELECTRICAL  LINES 
USED  TO  CONNECT  LSS  TO  SUIT 

• EMU  FRONT-TO-BACK  DIMENSION  OF  30  IN. 


• ASTRONAUT  MANUAL  ACTIVATION  OF 
EMERGENCY  OXYGEN  SYSTEM 

• MULTIPLE  UMBILICAL  CONNECTIONS  FOR  LSS 
RESERVICE 

• INDIVIDUALLY  POWERED  LSS  FAN  AND  WATER 
PUMP.  WITH  WATER  SEPARATOR  AS  SEPARATE 
COMPONENT 

• NO  PLSS-TO-SPACECRAFT  UMBILICAL 
CAPABILITY 


• ASTRONAUT  PROVIDED  WARNINGS.  OXYGEN 
QUANTITY.  AND  SUIT  PRESSURE  ONLY 


• REDUNDANT  SUIT  AXIAL  LOAD  RESTRAINT  FOR 
KNEE  CONVOLUTE  JOINT  ONLY 


• LIMITED  SIZE  COMPONENT  MODULARITY 
(GLOVES)  WITH  SEWN  AND  ADHESIVE 
OVERTAPED  PRESSURE  RESTRAINT  AND 
BLADDER  TO  CONVOLUTE  JOINT  INTEGRATION. 
CORD-WRAPED  AND  ADHESIVE-BONDED 
FABRIC  PRESSURE  RESTRAINT  AND  BLADDER 
HARDWARE  ATTACHMENT 


• PRESSURE-SEALING  SLIDE  FASTENER  ENTRY 
CLOSURE 

• METAL  CABLES  AND  SWAGES  FOR 
AXIAL  RESTRAINT  LOADS 

• NEOPRENE-COATED  NYLON  BLADDER 
FABRIC 


• SEWN  AND  ADHESIVE  BONDED  AND  TAPED 
BLADDER  SEAMS 

• DIPPED  CONVOLUTE  JOINT  ELEMENTS 

• INDIVIDUAL  LAYER  TAPED  SEAMS  FOR 
THERMAL  MICROMETEOROID  GARMENT 
INSULATION 


FIGURE  3.-  DESIGN  DIFFERENCES  BETWEEN  SHUTTLE  AND 
APOLLO  EMU'S. 


The  two  major  challenges  met  in  the  development  of  the  Shuttle  EMU  are 

1.  Enhancement  of  astronaut  EVA  operations 

2.  Capability  for  multiple  mission  reuse  by  male  ar.d  female  astronauts 

The  design  approaches  and  problems  experienced  in  meeting  these  challenges  are  presented  in  this 
paper. 


ENHANCEMENT  OF  ASTRONAUT  EVA  OPERATIONS 


LIFE  SUPPORT  SYSTEM  AND  SPACE-SUIT  INTEGRATION 

Elimination  of  the  requirement  that  the  space  suit  be  compatible  with  the  Orbiter  life  support 
system  for  astronaut  protection  in  the  event  of  loss  of  cabin  pressure  provided  the  first  opportunity 
in  U.S.  manned-space-flight  history  to  optimize  the  EMU  design  solely  for  EVA  operation.  Deleted 
were  design-compromising  interface  requirements  between  the  space  suit  and  the  crew  station,  the 
couches,  and  the  vehicle  life  support  system.  Operating  with  these  requirements  necessitated  assembly 
and  disassembly  of  the  Apollo  EMU  in  flight,  and  attachment  and  removal  of  the  portable  life  support 
system  while  the  space  suit  was  worn.  This  approach  required  separate  portable  life  support  system 
attachment  straps  and  mounting  brackets,  with  multiple  hoses  and  connections  for  ventilation  oxygen, 
emergency  pressurization,  and  cooling  water.  Electrical  cables  had  to  be  connected  and  checked  out 
before  EVA.  The  optimization  of  the  Shuttle  EMU  for  EVA  operations  shown  in  figure  4 was  accom- 
plished by  completely  integrating  the  life  support  system  and  its  controls  and  displays  into  the 
upper  torso  portion  of  the  space  suit. 
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FIGURE  4.-  PLSS/DCM  TO  SPACE  SUIT  ATTACHMENT  METHODS. 


HARD  UPPER  TORSO  CONFIGURATION 

A rigid  aluminum,  formed  upper  torso  that  conformed  to  the  shape  of  the  body  was  initially  selec- 
ted to  provide  a dimensionally  fixed  life  support  system  mounting  structure.  This  hard  upper  torso 
(HUT)  design  provided  the  capability  to  incorporate  shoulder  bearings,  which  significantly  increased 
astronaut  arm  mobility.  This  configuration  was  changed,  however,  after  excessive  difficulty  in 
donning  and  doffing  satisfactori ly  was  revealed  during  development  testing. 

The  donning  and  doffing  problem  caused  by  the  aluminum  HUT  and  shoulder  bearing  configuration  was 
solved  by  incorporating  gimbaled  shoulder  bearings  which  pivoted  at  the  hard  upper  torso,  with  a lam- 
inated fabric  bellows  interface  for  pressure  integrity.  This  design  increased  upward  movement  of  the 
upper  arms  during  donning.  The  complex  geometry  of  the  shoulders  and  neck  area  resulting  from  this 
design  change  made  aluminum  forming  of  the  HUT  undesirable.  Fiberglass  material  was  then  selected. 
This  material  permitted  molding  of  the  shell  and  the  integral  layup  and  bonding  of  the  gas  ventila- 
tion and  cooling  water  ducting  into  the  upper  torso  structure  and,  thus,  provided  a smooth  and  more 
comfortable  internal  profile. 


LIFE  SUPPORT  SYSTEM  DESIGN  APPROACH 

A closed-loop  life  support  system  similar  to  the  configuration  developed  for  the  Apollo  Program 
was  selected  for  Shuttle  use,  as  shown  schematically  in  figure  5,  rather  than  the  umbilical-type  sys- 
tems used  during  the  Gemini  and  Skylab  Programs.  The  closed-loop  concept  is  superior  for  the  Shuttle 
application  since  vehicle  dependency  is  minimized  and  astronauts  are  freed  from  managing  bulky 
umbilicals. 
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FIGURE  5.-  SPACE  SHUTTLE  EMU  SCHEMATIC. 


The  primary  life  support  system  (PLSS)  of  the  Shuttle  EMU  provides  cooling  of  the  astronauts  by 
the  circulation  of  cool  water  through  smal 1 -diameter  tubes  contained  in  the  liquid  cooling  and  ven- 
tilation garment.  A water  sublimator  and  heat  exchanger,  similar  in  concept  to  that  of  the  Apollo 
unit,  is  used  to  cool  the  water  and  also  to  cool  and  dehumidify  the  oxygen  in  the  recirculating 
ventilation  loop.  As  in  the  Apollo  EMU,  lithium  hydroxide  and  charcoal  are  used  to  remove  carbon 
dioxide  (CO2)  and  odors  from  the  oxygen  gas  stream  of  the  Shuttle  EMU. 

Makeup  oxygen  is  regulated  to  4.3  psi  from  twin  1000-psi  PLSS  storage  tanks  shown  in  figure  6. 

A secondary  oxygen  package  (SOP)  located  below  the  PLSS  provides  30  minutes  of  emergency  purge  flow 
from  two  6000-psi  spheres.  The  SOP  is  brought  on  standby  just  before  EVA,  using  the  valve  actuator 
shown  in  figure  7,  and  provides  flow  automatically  any  time  suit  pressure  drops  below  4.0  psi.  Con- 
trols and  displays  are  located  on  the  displays  and  control  module  (DCM)  (fig.  8),  which  is  mounted 
on  the  front  of  the  HUT.  A silver  oxide/zinc  battery  provides  power  for  the  radio,  the  caution  and 
warning  system,  and  the  fluid  circulation  equipment. 
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FIGURE  6.-  SHUTTLE  EMU  PLSS. 
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FIGURE  7.-  SOP  WITH  FOUR-POSITION  ACTUATOR  VALVES 
AND  LINKAGE. 


FIGURE  8.-  DCM  FRONT  VIEW. 
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FIGURE  9.-  APOLLO  EMU  PLSS  FLUID  HOSES. 


EMU  FRONT-TO-BACK  DIMENSION 

Shuttle  EMU  designers  found  that  the  Orbiter  Interdeck  hatch  passthrough  requirement  Imposed  a 
front-to-back  dimensional  constraint  which  ruled  out  conventional  plumbing  methods  for  coupling  the 
components  and  subsystems  of  the  EMU.  Figures  9 and  10  show  the  various  runs  of  tubing  and  hoses 
required  for  the  Apollo  life  support  system.  Selection  of  this  approach  for  Shuttle  would  have 
increased  the  envelope  size  to  unacceptable  dimensions,  because  of  not  only  the  physical  size  of 
the  hoses  and  fittings  Involved  but  also  the  space  required  for  tool  Insertion  In  assembly  and 
disassembly. 

The  approach  selected  to  solve  this  problem  was  modularization  of  the  entire  life  support  sys- 
tem. The  Shuttle  PLSS  is  divided  into  the  following  three  modules  (fig.  6). 

1.  Time  dependent  module  (TDM) 

2.  Time  independent  module  (TIM) 

3.  Major  electronics  module  (MEM) 

The  TDM  consists  of  components  the  physical  size  of  which  Is  a function  of  mission  time  or  total  meta- 
bolic load  or  both.  These  components  are  the  water  tanks,  the  battery,  the  contaminant  control  car- 
tridge (CCC),  and  the  oxygen  subsystem.  The  water  tanks  are  shaped  to  conform  to  the  contour  of  the 
back  of  the  HUT  and,  In  combination  with  protective  shrouds  around  the  oxygen  tanks,  form  an  inte- 
grated structure  for  the  PLSS.  This  structure  provides  attachment  points  for  the  airlock  adapter 
plate  ( AAP ) , used  for  flight  stowage  and  as  a holding  fixture  for  donning  and  doffing,  and  for  the 
manned  maneuvering  unit  (MMU).  The  CCC  and  the  battery  are  nested  together  in  a rear  cavity  of  the 
PLSS;  this  configuration  provides  easy  access  for  recharge  and  maintains  a dense  package. 

The  TIM  consists  of  a valve  module,  which  provides  internal  connecting  water  and  gas  lines,  plus 
provisions  for  mounting  cartridge-type  valves,  transducers,  a sublimator,  and  rotating  machinery. 
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FIGURE  10.-  APOLLO  EMU  PLSS  COMPONENT  LAYOUT. 


The  MEM  components,  which  are  mounted  on  top  of  the  TIM,  consist  of  the  caution  and  warning  system, 
the  extravehicular  communications  radio,  and  a CO?  sensor.  The  SOP  fits  snugly  at  the  bottom  of  the 
PLSS. 


The  packaging  density  achieved  in  the  Shuttle  life  support  system  is  80  percent,  compared  to  40 
percent  for  the  Apollo  life  support  system. 


ELIMINATION  OF  EXPOSED  OXYGEN  VENTILATION  HOSES 

By  flange  mounting  the  PLSS  and  the  DCM  to  the  HUT  as  shown  in  figure  1,  designers  not  only  en- 
hanced Shuttle  EMU  packaging  and  met  the  19-3/4-inch  front-to-back  dimensional  requirement,  they  also 
solved  one  of  the  most  worrisome  problems  of  the  Apollo  EMU  design  - exposed  ventilation  hoses.  Rup- 
ture or  severe  damage  to  the  Apollo  PLSS  hoses  could  have  had  catastrophic  results,  since  severe  loss 
of  pressure  integrity  could  easily  have  exceeded  emergency  oxygen  system  capability. 


ASTRONAUT  MOBILITY 

One  of  the  more  important  requirements  for  efficient  performance  of  EVA  tasks  in  the  zero-g  envi- 
ronment is  astronaut  upper  body  mobility.  Shuttle  EMU  upper  body  mobility  is  superior  to  that  of  the 
Apollo  EMU  as  a result  of  incorporating  gimbaled  bearing  shoulder  joints,  a gimbaled  wrist  joint  in 
each  glove,  and  a waist  bearing.  This  configuration  resulted  in  the  increased  mobility  ranges  shown 
in  figure  11. 

The  objective  to  increase  lower  torso  mobility  for  the  Shuttle  EMU  was  initially  considered  but 
was  not  implemented  because  of  the  lack  of  a walking  requirement  in  zero  g and  the  disadvantages  of 
additional  design  complexity,  weight,  and  increased  development  and  manufacturing  costs.  As  a re- 
sult, the  lower  body  mobility  of  the  Shuttle  EMU  is  less  than  that  of  the  Apollo  EMU. 

The  flat  patterned  fabric  joints  shown  in  figure  12  were  selected  for  the  Shuttle  EMU  because  of 
their  increased  flexure  cycle  life  and  reduced  manufacturing  cost. 
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FIGURE  12.-  SPACE-SUIT  MOBILITY-JOINT  DESIGN 
APPROACHES. 


FIGURE  13.-  FAN/PUMP/SEPARATOR  ASSEMBLY. 


Section  A-A 


FIGURE  14.-  SUBLIMATOR. 


FAN  OPERATION  AT  SEA-LEVEL  ATMOSPHERE 

The  Shuttle  EMU  provides  astronaut  ventilation  during  a 3-1/2-hour  oxygen  prebreathe  period  at 
sea-level  pressure  followed  by  airlock  depressurization  to  vacuum  and  suit  pressure  control  at  4.3 
psia.  In  Apollo  missions,  the  5-psia,  100-percent  oxygen  lunar  module  cabin  atmosphere  eliminated 
the  need  for  prebreathing  and  reduced  the  fan  design-load  requirements.  The  requirement  for  Shuttle 
EMU  fan  operation  over  a wide  range  of  pressures  was  solved  by  the  development  of  a motor  with  speed 
limiting  circuitry  so  that  virtually  all  operating  conditions  are  met  within  speed  variations  of  less 
than  15  percent.  To  sense  rotor  position,  two  Hall -effect  electromagnetic  sensors  shown  in  figure  13 
are  used  for  commutation,  and  power  input  is  "chopped"  at  the  lower  pressure  during  EVA  to  control 
speed  and  decrease  power  consumption.  The  Apollo  EMU  fan  was  limited  to  momentary  operation  at  sea- 
level  pressure  to  prevent  overheating  of  its  motor  winding. 


PLSS  OPERATION  IN  ZERO  g 

Separation  and  removal  of  humidity  in  the  PLSS  ventilation  loop  occurs  in  two  stages.  First, 
the  gas  stream  is  cooled  in  the  sublimator  and  the  resulting  condensate  spreads  over  fins  coated  with 
a hydrophilic  substance.  It  is  then  transported  by  pressure  differential  through  holes  into  a collec- 
tion manifold,  called  the  "slurper"  (fig.  14),  where  the  mixture  of  ventilation  oxygen  and  water 
enters  a rotating  drum  and  stationary  pitot  assembly.  The  drum  is  mounted  to  the  motor  shaft  at  the 
fan  inlet  shown  in  figure  13,  and  the  driving  force  for  the  slurper  is  the  fan  pressure  rise.  When 
spinning  at  about  19  000  rpm,  the  tapered  drum  slings  the  water  droplets  to  the  periphery  of  the  hous- 
ing, where  the  water  stream  contacts  a stationary  pitot  tube.  As  much  as  25  psid  pressure  can  be  de- 
veloped in  this  manner,  and  the  water  is  pumped  either  into  the  EMU  water  storage  tanks  or  directly 
to  the  sublimator  for  immediate  heat-rejection  use.  The  water-free  oxygen  stream  is  returned  to  the 
fan  inlet.  Thus,  unlike  the  Apollo  EMU  wherein  condensate  was  stored  and  dumped  at  the  end  of  an  EVA, 
the  Shuttle  EMU  makes  use  of  metabolically  generated  water  and  thereby  allows  a reduction  in  stored 
water  requirements.  This  approach  aided  in  the  attainment  of  the  compact  PLSS  packaging. 
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The  tasks  of  ventilation  at  various  system  pressures,  water  circulation,  and  moisture  removal 
from  the  ventilation  loop  are  accomplished  by  the  integrated  fan/pump/separator  assembly  shown  in  fig- 
ure 13.  The  high  efficiency  of  this  assembly  is  illustrated  by  noting  that  the  Shuttle  water  pump 
consumes  only  2 watts,  compared  to  10  watts  for  the  Apollo  pump. 

In  addition  to  water  in  the  gas  stream,  the  opposite  problem  also  exists  - the  presence  of  as 
much  as  30  cubic  inches  of  unwanted  gas  bubbles  in  the  cooling  water  loop.  These  bubbles  are  pro- 
duced by  (1)  attachment  of  a liquid  cooling  garment  partly  filled  with  water  or  (2)  evolution  due  to 
the  system  pressure  reduction  during  depressurization.  In  Apollo  missions,  lunar  1/6-g  force  pro- 
vided the  means  of  separation  and  the  loop  was  periodically  "burped"  to  remove  gas.  In  the  Shuttle 
EMU,  a fine  mesh  (18  micrometer)  cylindrical  screen  shown  in  figure  15  receives  the  full  240-lb/hr 
cooling  loop  waterflow,  delivered  by  a centrifugal  pump  magnetically  coupled  to  the  motor  shaft.  The 
screen  has  a very  low  flow  resistance  to  water  and  a very  high  (comparative)  resistance  to  gas  flow 
so  that  water  flows  radially  outward,  and  gas  bubbles  and  a small  flow  of  water  are  carried  out 
through  the  exit  orifice  and  into  the  water  separator  described  previously. 


IN-FLIGHT  CHECKOUT  AND  STATUS  MONITORING 

During  Apollo  missions,  the  EMU  was  donned  and  checked  following  a written  checklist,  and  EMU 
performance  during  EVA  was  monitored  by  ground  controllers  using  telemetry,  which  required  an  exten- 
sive real-time  EVA  support  team.  In  addition  to  an  oxygen  pressure  tank  "gas  gage,"  the  Apollo  EVA 
astronaut  had  a suit  pressure  gage  and  five  electromechanical  warning  flags  to  alert  him  of  EMU  sys- 
tem malfunctions. 

The  Shuttle  EMU  caution  and  warning  system  shown  in  figure  16  uses  a microprocessor  and  slightly 
more  than  5 kilobits  of  memory  to  provide  the  user  with  procedures  to  be  used  during  checkout,  to 
allow  tracking  of  limiting  consumables  during  EVA,  and  to  provide  notification  of  out-of-limit  condi- 
tions with  appropriate  corrective  actions.  This  approach  puts  the  information  directly  at  the  point 
where  action  can  be  taken  - with  the  user.  Continuing  the  effort  to  make  the  EMU  "user  friendly," 
all  controls  and  displays  are  located  on  the  DCM  shown  in  figure  8.  By  contrast,  the  Apollo  PLSS  had 
the  suit  cooling  water  control  valve,  the  sublimator  on/off  valve,  and  the  primary  oxygen  supply 
valve  located  on  a remote  lower  corner  of  the  backpack,  which  was  difficult  to  reach. 


IN-FLIGHT  RECHARGE 

In-flight  recharge  of  water,  oxygen,  and  electrical  power  is  accomplished  through  a common  con- 
nector located  on  the  DCM  shown  in  figure  8.  One  connection  accomplishes  the  same  task  as  several 
connections  made  separately  on  the  Apollo  backpack.  The  service  and  cooling  umbilical  (SCU),  which 
mates  to  the  common  connector,  also  allows  the  recirculation  of  water  for  cooling  the  astronaut  dur- 
ing suited  operations  before  airlock  depressurization  using  the  PLSS  pump  and  an  Orbiter  heat  ex- 
changer. The  Apollo  EMU  had  no  such  PLSS  capability.  Removal  of  the  CCC  involves  unzipping  a flap 
on  the  PLSS  thermal  cover,  releasing  two  latches,  and  pulling  out  the  expended  can,  with  a reversal 
of  steps  to  install  a new  one.  The  battery  can  also  be  replaced  instead  of  being  recharged  in  place 
to  expedite  reuse.  Total  recharge  time  is  about  1 hour  if  the  battery  is  replaced  rather  than  being 
recharged.  Battery  recharge  takes  approximately  19  hours. 


FIGURE  15.-  GAS  TRAP. 


FIGURE  16.-  CAUTION  AND  WARNING  SYSTEM  BLOCK 
DIAGRAM. 
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SPACECRAFT  UMBILICAL  OPERATION 


Although  umbilicals  have  appreciable  drawbacks  from  the  crew  handling  aspect,  there  are  cases  in 
which  umbilical  EVA  capability  might  be  useful.  For  example,  consider  a payload  benefiting  from  EVA 
but  with  a sensitivity  to  water  vapor  contamination.  Use  of  the  standard  Shuttle  EMU  would  not  be  ap- 
propriate because  of  the  EMU  sublimator  exhaust,  but  water  vapor  emission  could  be  avoided  by  using 
suit  cooling  water  chilled  by  the  vehicle's  radiator-based  heat-rejection  system  and  circulated  by 
the  PLSS  pump.  Another  instance  might  require  that  an  astronaut  plan  to  extend  an  EVA  past  the  ex- 
pendables limits.  By  using  an  extended  length  SCU  with  its  water  circulation,  power,  and  oxygen 
lines,  the  Shuttle  EMU  will  provide  this  capability. 


CAPABILITY  FOR  MULTIPLE  MISSION  REUSE 
BY  MALE  AND  FEMALE  ASTRONAUTS 


SPACE-SUIT  SIZING  TO  ACCOMMODATE  FEMALES  AND 
A LARGE  SIZE  POPULATION  OF  ASTRONAUTS 

The  large  number  of  planned  Shuttle  missions  results  in  a large  astronaut  size  population  to  be 
accommodated  with  correctly  sized  and  fitted  space  suits.  The  scope  of  the  requirement  to  satisfacto- 
rily fit  both  female  and  male  Shuttle  astronauts  whose  body  dimensions  vary  from  5th  percentile  fe- 
male to  the  95th  percentile  male  is  shown  in  figure  17.  The  design  approach  to  meet  this  large  varia- 
tion in  body  dimensions  was  to  use  a modular  system  of  interchangeable,  standard-sized  components 
shown  in  figure  18.  Unlike  the  Apollo  approach  to  manufacture  custom-sized  suits  using  individual 
astronaut's  measurements,  the  Shuttle  suit  design  approach  provides  the  capability  to  "custom- 
assemble"  previously  manufactured  and  "on  the  shelf"  standard  size  components.  After  mission  use,  the 
Shuttle  suit  is  disassembled  and  components  are  made  available  for  subsequent  mission  use  by  another 
astronaut.  The  critical  design  feature  necessary  to  allow  for  the  modularity  of  the  standard  size 
components  was  the  flange  mounting  of  fabric  restraint  and  bladder  components  to  joint  bearings  and 
disconnects  shown  in  figure  19.  By  removing  a series  of  circumferentially  spaced  screws  and  a mount- 
ing ring,  different  standard-sized  fabric  components  can  be  interchanged  easily.  Pressure  integrity 
between  the  fabric  bladder  material  and  the  bearing  or  disconnect  is  assured  by  use  of  an  0-ring 
seal.  The  Apollo  suit  design  approach  used  adhesive  bonding  of  the  fabric  bladder  to  hardware  with 
a cord  overwrap  to  provide  adequate  structural  integrity.  Removal  of  either  side  of  this  interface 
was  difficult  and  required  considerable  time  and  effort  since  adhesive  removal,  surface  cleaning,  and 
long  adhesive  cure  times  were  necessary. 

Figure  20  shows  the  different  standard-sized  suit  components  required  for  the  pressure  retention 
portion  of  the  Shuttle  EMU  space  suit.  Standard  sizes  of  thermal  micrometeoroid  garment  components. 


CRITICAL 

BODY 

DIMENSIONS 

5TH 

PERCENTILE 
FEMALE,  IN. 

95TH 

PERCENTILE 
-TO-  MALE,  IN. 

MAX.  SIZE 
VARIATION,  IN 

CHEST  BREADTH 

9.9 

14.5 

4.6 

CHEST  DEPTH 

8.2 

10.9 

2.7 

CHEST  CIRCUMFERENCE 

32.4 

43.2 

10.8 

SHOULDER  CIRCUMFERENCE 

36.7 

50.6 

13.9 

SHOULDER  BREADTH 

15.2 

18.4 

3.2 

SHOULDER  HEIGHT 

48.4 

61.7 

13.3 

FINGERTIP  SPAN 

60.0 

77.0 

17.0 

TORSO  LENGTH 

22.1 

27.7 

5.6 

HIP  BREADTH 

12.4 

15.3 

2.9 

CROTCH  HEIGHT 

26.8 

36.8 

10.0 

KNEE  HEIGHT 

15.0 

21.3 

6.3 

STANDING  HEIGHT 

59.9 

74.3 

14.4 

FIGURE  17.-  SHUTTLE  EMU  SPACE  SUIT  ASTRONAUT  SIZE 
REQUIREMENTS  AND  VARIATION. 
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HELMET 


FIGURE  18.-  SHUTTLE  EMU  SPACE-SUIT  COMPONENT 
MODULARITY  AND  LENGTH  SIZING  ADJUSTMENTS. 


SHUTTLE  FLAME  MOUNTING  APOLLO  CORO  WRAPPED  ADHESIVE 
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FIGURE  19.-  SPACE-SUIT  PRESSURE  RESTRAINT  AND 
BLADDER  TO  HARDWARE  ATTACHMENT  METHODS. 


liquid  cooling  ventilation  garment,  and  communication  carrier  are  also  necessary.  The  quantity  of 
possible  size  combinations  of  each  major  component  of  the  space  suit  is  also  identified. 


AGE  AND  OPERATING  LIFE 

The  Shuttle  EMU  is  designed  for  multiple  mission  reuse,  as  compared  to  the  single  mission  use 
required  for  the  Apollo  EMU.  This  design  resulted  in  increased  age  and  operating  life  requirements 
for  the  Shuttle  EMU  space-suit  assembly  and  life  support  system. 


Space-Suit  Assembly 

To  accomplish  multiyear,  multimission  capability  for  the  suit,  a requirement  for  6 years  age 
life  for  nonmetallic  materials  and  15  years  for  metallic  hardware  was  implemented.  This  compares 
with  the  4-year  age  life  capability  of  the  Apollo  EMU  suit  design.  The  6-year  age  life  requirement 
resulted  in  the  selection  of  polyurethane-coated  nylon  fabric  for  the  Shuttle  suit  pressure  bladder 
in  lieu  of  the  neoprene-coated  nylon  fabric  and  the  combination  neoprene  and  natural  rubber  convolute 
compound  used  in  the  Apollo  suit.  The  6-year  life  requirement  resulted  in  a 462-hour  manned  pressur- 
ized operating  lifetime  requirement  as  compared  with  the  105-hour  capability  of  the  Apollo  EMU  suit 
design. 

Low  endurance  life  components  used  for  the  Apollo  suit  had  to  be  replaced  as  a result  of  this 
longer  life  requirement.  These  included  the  Apollo  suit  pressure-sealing  slide  fastener  used  for 
donning  and  doffing.  This  component  was  found  to  be  life  limited  to  approximately  50  opening  and 
closing  cycles,  with  an  average  of  3 replacements  required  in  each  Apollo  flight  suit  before  launch. 
The  Shuttle  suit  design  uses  an  oval-shaped  metal  disconnect  to  attach  the  hard  upper  torso  to  the 
lower  torso  assembly,  and  the  device  is  not  cycle  life  limited. 

To  increase  the  reliability  of  the  suit  for  multiple  mission  use,  a redundant  axial  load  re- 
straint design  shown  in  figure  21  was  incorporated  into  all  fabric  pressure  restraint  elements.  This 
design  consists  of  independent  webbings,  sewn  together  to  maintain  joint  stability,  which  have  sepa- 
rate hardware  attachment  brackets.  In  the  event  of  a primary  restraint  webbing  failure,  the  redun- 
dant restraint  webbing  and  brackets  are  capable  of  maintaining  suit  pressure  integrity  to  enable  com- 
pletion of  three  7-hour  EVA's  on  a mission  with  minimum  effect  on  astronaut  mobility. 

Figure  22  shows  the  different  bladder  seam  design  approaches  used  for  the  Shuttle  and  Apollo  EMU 
suits.  The  heat-sealed  bladder  seam  design  was  selected  for  the  Shuttle  suit  to  reduce  seam  leakage, 
which  was  a recurring  problem  with  the  Apollo  suits,  and  also  to  reduce  manufacturing  time  and  cost. 
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FIGURE  20.-  SHUTTLE  EMU  SPACE-SUIT  SIZING  SYSTEM  - PRESSURE  RETENTION  ASSEMBLY. 


FIGURE  21.-  SHUTTLE  SPACE  SUIT  REDUNDANT  AXIAL 
LOAD  RESTRAINT  DESIGN. 
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FIGURE  22.-  SPACE-SUIT  BLADDER  SEAM  DESIGN 
APPROACHES. 


Life  Support  System 

The  Apollo  backpacks  were  left  on  the  lunar  surface  following  their  final  EVA  mission  use.  As  a 
result,  required  operating  lifetime  was  low,  and  there  was  no  requirement  for  mission  reuse  capability. 

The  goal  of  15-year  service  life  for  the  Shuttle  life  support  system  with  mission  to  mission 
reuse  was  approached  by  determining  from  the  mission  model  and  required  hardware  turnaround  time  the 
number  of  units  required  and,  then,  certifying  for  the  required  number  of  operating  hours  and  cycles. 
For  example,  a typical  EMU  fan  motor  cap  be  expected  to  operate  for  slightly  more  than  1500  hours 
from  STS-11  through  fiscal  year  1995,  and  the  DCM  status  switch  can  be  expected  to  undergo  about 
145  000  cycles. 

Naturally,  a considerable  amount  of  ground  maintenance  will  be  necessary  over  this  long  time  pe- 
riod. The  modular  accessible  design  shown  in  figure  6 enhances  rapid  replacement  of  components.  For 
example,  13  components  plug,  cartridge  fashion,  into  the  valve  module. 
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The  Shuttle  EMU  aluminum  porous  plate  sublimator  is  much  smaller  (one-sixth  the  plate  area)  and 
much  lighter  (3.2  pounds  compared  to  7.7  pounds)  than  the  Apollo  EMU  unit.  Its  small  size  helped  in 
achieving  the  reduced  Shuttle  EMU  envelope.  Significantly  less  plate  area  is  required,  and  a single 
porous  plate,  which  is  bolted  to  one  side  of  the  unit,  is  used.  Since  it  is  removable,  it  may  be 
cleaned  and/or  replaced. 


CONCLUDING  REMARKS 


The  majority  of  the  operational  EVA  experience  planned  for  the  Space  Shuttle  lies  ahead.  How- 
ever, the  success  of  the  EVA  demonstration  conducted  during  the  STS-6  mission  is  significant.  Also, 
although  the  actual  Shuttle  EVA  mission  time  to  date  is  relatively  small  (fig.  23),  the  Shuttle  EMU 
has  already  exceeded  EMU  time  at  vacuum  (fig.  24)  for  the  total  Apollo  Program,  principally  because 
of  the  15-year-life  certification  and  chamber  training  of  astronauts  conducted  for  each  Shuttle  mis- 
sion. Figure  25  shows  the  accumulated  manned  operating  pressure  time  of  the  EMU  space  suit,  including 
operating  time  in  which  only  life  support  system  mockups  are  used,  such  as  for  underwater  neutral- 
buoyancy  training.  Based  on  this  impressive  accumulation  of  EMU  system  operational  time,  the  current 
indications  are  that  the  EMU  development  challenges  are  being  met. 
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ABSTRACT 


A number  of  major  challenges  were  faced  in  the  design  and  development  of  the  Orbiter  Active 
Thermal  Control  Subsystem  (ATCS).  At  the  system  level,  the  initial  challenges  were  to  define  an 
approach  that  would  Interface  dual  Freon  coolant  loops  with  multiple  coolant  loops  from  other 
vehicle  subsystems  with  the  lowest  weight  penalty  to  the  Orbiter;  and  to  provide  highly  responsive 
vehicle  heat  rejection  throughout  all  of  the  Orbiter  mission  phases. 

Optimized  heat  exchangers,  representing  an  advance  in  the  state-of-the-art  in  heat  exchanger 
design,  were  developed  to  transfer  heat  between  the  orbiter  Freon  coolant  loops  and  five  other 
vehicle  systems.  The  heat  exchangers  Interface  four  or  five  separate  coolant  loops  in  a single 
unit  while  maximizing  performance  and  minimizing  weight,  volume  and  coolant  loop  pumping  power. 
This  paper  includes  a description  of  the  various  heat  exchanger  configurations,  optimization 
techniques  used  in  their  design  and  performance  characteristics  realized  during  testing  and  flight 
operations. 

Flash  evaporation  was  selected  as  a highly  efficient  and  responsive  means  for  cooling  the  Orbiter 
Freon  loops  during  ascent  and  entry.  It  also  provides  supplemental  cooling  on-orbit.  The  Flash 
Evaporator  Subsystem  (FES)  utilizes  cyclic  water  spray  cooling  in  a chamber  maintained  at  or  below 
the  water  triple  point  pressure.  Because  of  the  dynamic  nature  of  the  flash  evaporation  process, 
challenges  were  faced  in  hardware  and  control  scheme  development  and  in  performance  verification 
testing  of  the  subsystem  under  flight  simulated  conditions.  This  paper  includes  a summary  of  the 
basic  heat  transfer  research  conducted  by  Rice  University  to  identify  the  fundamental  heat 
transfer  processes  involved  in  water  spray  cooling  In  support  of  the  FES  design.  Also  Included  Is 
a discussion  of  the  high  fidelity  dynamic  analytical  model  of  the  FES  that  was  generated  to  aid  in 
the  design  of  control  logic,  evaluate  performance  and  simulate  ground  test  and  flight  anomalies. 
A description  of  the  FES  and  Integrated  ATCS  testing  conducted  in  the  SESL  chamber  A at  NASA-JSC 
is  also  presented. 
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mass  of  Freon  In  core  wall  segment  "1",  lbm 
specific  heat  of  Freon,  Btu/lbm-°F 
average  temperature  of  Freon  in  core  segment  "1",  °F 
time,  sec 

Freon  flow,  lbm/sec 

inlet  Freon  temperature  at  segment  "i",  °F 

exit  Freon  temperature  at  segment  "i",  °F 

Freon  film  coefficient,  Btu/hr-ft2-°F 
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specific  heat  of  core  wall  metal,  Btu/lbm-°F 

conductance  between  core  wall  segments,  Btu/hr-°F 

wall  temperature  of  core  segment  "1-1",  °F 

wall  temperature  of  core  segment  "1+1",  °F 

heat  loss  from  wall  segment  "1"  to  evaporate  water,  Btu/hr 

water  spray  angle 

cumulative  mass  of  water  sprayed  into  core  up  to  angle (3 
as  a fraction  of  the  total 

curve  fit  constant  equal  to  the  water  spray  angle  at  f(/3)  = 0.5 
curve  fit  constant  equal  to  the  slope  of  f(0)  at  f(/3)  = 0.5 


INTRODUCTION 


Because  the  nature  of  the  Space  Shuttle  mission  is  different  from  previous  spacecraft,  new  chal- 
lenges were  faced  in  the  design  and  development  of  the  Orbiter  Active  Thermal  Control  Subsystem 
(ATCS).  Hardware  weight  and  volume  have  always  been  of  paramount  concern  in  spacecraft  design. 
However,  they  take  on  added  importance  for  the  orbiter  since  it  Is  reusable  and  every  pound  of 
hardware  weight  must  be  launched  to  low  earth  orbit  a maximum  of  100  times  during  the  life  of  the 
vehicle.  Economics  also  had  a stronger  influence  on  the  orbiter  hardware  design  than  on  previous 
spacecraft.  Every  pound  of  orbiter  equipment  displaces  a pound  of  payload  and  the  revenue  that 
could  be  realized  from  that  payload. 

Reliability,  ground  maintenance  and  turn-around  time  also  were  strong  considerations  in  the  system 
design  phase.  In  order  to  provide  an  economically  viable  Space  Transportation  System,  the  Shuttle 
must  be  kept  flying  with  a maintenance  philosophy  approaching  that  of  a commercial  airline. 

These  design  drivers  made  it  doubly  Important  to  optimize  the  ATCS  from  a performance,  weight  and 
volume  standpoint,  while  providing  sufficient  redundancy  and  flexibility  to  accommodate  failures 
during  flight  without  adversely  affecting  the  mission  or  ground  turn-around  time. 

Extensive  system  engineering  optimization  studies,  a basic  research  program,  sophisticated  dynamic 
computer  analyses  and  extraordinary  testing  were  used  to  meet  the  ATCS  challenges. 

Both  system  and  component  level  challenges  were  encountered  during  the  design  and  development 
phases  of  the  Shuttle  ATCS  program.  Some  of  the  most  challenging  areas  are  discussed  in  the  fol- 
lowing sections. 


SYSTEM  DEFINITION 

Providing  the  desired  flexibility  at  minimum  weight  and  volume  was  the  biggest  challenge  at  the 
system  level.  The  ATCS  performs  the  following  three  basic  functions: 

o Cools  or  heats  other  subsystems  through  interface  heat  exchangers, 
o Transports  heat  from  sources  to  sinks  by  means  of  dual  Freon  coolant  loops, 
o Rejects  heat  by  various  means  dependent  on  mission  phase. 

A functional  block  diagram  of  the  subsystem  is  shown  in  Figure  1. 
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FIGURE  1 FREON  COOLANT  LOOP  SCHEMATIC 


Other  equipment  cooled  or  heated  by  the  ATCS  includes: 

o Cabin  Atmosphere  Revitalization  Subsystem  - two  redundant  water  coolant  loops, 
o Fuel  Cell  Power  Systems  - three  separate  FC-40  coolant  loops, 
o Payloads  - two  separate  payload  coolant  loops  using  either  Freon  or  water, 
o Hydraulic  Systems  - three  separate  hydraulic  fluid  loops, 
o Cold  Plate  mounted  electronic  equipment. 

(Only  one  each  of  the  interfacing  coolant  loops  is  shown  in  Figure  1.) 

Heat  transport  from  heat  sources  to  heat  sinks  is  provided  by  dual  Freon-21  coolant  loops  (only 
one  loop  is  shown  in  Figure  1).  Extensive  trade-off  studies  were  performed  during  the  shuttle  de- 
finition phase  to  arrive  at  the  optimum  mode  of  operation.  The  mode  selected  was  that  of  operat- 
ing both  Freon  loops  normally  with  single  loop  operation  only  in  a failure  mode  providing  on-line 
redundancy  rather  than  standby  redundancy.  This  approach  saved  considerable  fixed  weight  and 
power  over  an  approach  where  a single  loop  provides  total  cooling  during  normal  operation  with  the 
second  redundant  loop  on  standby.  The  dual  loop  approach  does  require  redundant  pumps  In  each 
loop  and  a reduction  in  heat  load  (power  usage)  from  normal  when  only  one  loop  is  operating. 
This,  however,  was  deemed  acceptable  In  a failure  case  and  does  not  adversely  affect  the  safety  of 
the  crew  and  vehicle. 

Heat  rejection  must  be  provided  during  a number  of  vastly  different  mission  phases  by  different 
means.  Trade-off  studies  during  the  shuttle  definition  phase  resulted  In  the  need  for  four  dif- 
ferent heat  sink  devices  to  provide  heat  rejection  during  all  of  the  mission  phases.  The  major 
mission  phases  and  the  type  of  heat  rejection  provided  are: 

o Prelaunch/Postlanding  - ground  support  equipment  cooling 
o Launch  - thermal  inertia 
o Ascent/Entry  - water  evaporation 

o On-orbit  - space  radiation  with  supplemental  water  evaporation 
o Landing  - ammonia  evaporation 
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Prior  to  launch  and  at  some  time  after  landing,  cooling  is  provided  by  a ground  cart  refrigeration 
system.  A trade-off  study  was  conducted  that  resulted  in  the  use  of  a permanently  installed 
Ground  Support  Equipment  (GSE)  heat  exchanger  in  the  orbiter  cooling  loops  to  interface  with  the 
ground  cooling  loop.  Cold  Freon  is  supplied  to  the  vehicle  through  fly-away  quick  disconnects. 
The  high  GSE  Freon  flow  and  cold  temperature  minimize  heat  exchanger  size  and  weight.  Although  a 
small  weight  penalty  results  because  the  unit  must  be  carried  into  orbit  every  mission,  isolation 
is  provided  between  the  vehicle  and  ground  loops  resulting  in  a much  safer  and  more  reliable  de- 
sign. 

Heat  rejection  during  the  on-orbit  mission  phase  is  provided  by  radiation  to  space.  This  was  an 
obvious  choice  over  expendable  evaporation.  If  water  was  used  as  an  evaporant,  approximately 
16,400  lb  would  be  required  for  a seven  day  mission  (maximum  payload  heat  load)  while  the  fuel 
cell  would  produce  only  2400  lb  (available  for  heat  rejection ).  The  difference  (14,000  lb)  would 
have  to  be  carried  to  orbit  resulting  in  a tremendous  weight  penalty. 

Water  evaporation  was  the  choice,  however,  for  heat  rejection  following  launch  until  the  space 
radiator  is  deployed  and  during  entry  after  the  radiator  is  stowed  inside  the  payload  bay  doors. 
These  mission  phases  are  relatively  short  and  the  launch  weight  penalty  is  small.  Water  is  used 
as  the  evaporant  because  it  has  a latent  heat  of  vaporization  double  that  of  any  other  potential 
evaporant,  and  it  can  be  replenished  on-orbit  by  the  fuel  cells. 

The  water  evaporation  pressure  (saturation  pressure)  and  corresponding  saturation  temperature  must 
be  maintained  at  low  enough  levels  (less  than  0.1  psia  and  35°F)  to  cool  the  Freon  loops  to 
40° F.  An  altitude  above  approximately  140,000  ft  must  be  reached  before  the  desired  ambient 
pressure  is  attained.  For  this  reason  water  is  not  an  acceptable  evaporant  for  launch  and  landing. 

Prior  to  launch,  cooling  is  provided  by  ground  support  equipment.  It  takes  the  shuttle  slightly 
over  two  minutes  to  reach  an  altitude  where  water  evaporation  becomes  effective.  There  is  suffi- 
cient thermal  inertia  in  the  system  to  limit  the  Freon  loop  temperature  rise  that  active  heat  re- 
jection is  not  required  for  the  first  two  and  a half  minutes  of  launch. 

An  ammonia  boiler  is  used  to  provide  cooling  during  the  last  ten  minutes  of  flight  and  until 
ground  support  equipment  is  connected  (about  10  to  15  minutes  following  landing).  This  20  to  25 
minute  period  is  too  long  to  rely  totally  on  thermal  inertia.  Ammonia,  although  toxic,  is  the 
most  efficient  evaporant  with  the  exception  of  water,  having  a latent  heat  of  vaporization  about 
half  that  of  water.  But,  because  of  the  short  time  period  involved,  the  quantity  of  ammonia  re- 
quired is  small. 


SYSTEM  LEVEL  CHALLENGES 


An  integral  part  of  the  system  level  trade-off  studies  and  one  of  the  greatest  ATCS  challenges  was 
defining  an  efficient  means  for  interfacing  the  two  Freon  coolant  loops  with  the  multiple  cooling 
loops  from  other  systems.  The  result  was  an  innovative  heat  exchanger  design  approach  that  allows 
heat  transfer  between  four  or  five  separate  cooling  loops  in  a single  unit.  Another  major  chal- 
lenge resulting  from  the  system  level  studies  was  the  design  and  development  of  a highly  respon- 
sive, long  life,  low  maintenance  water  evaporator  that  operates  over  a large  range  of  heat  loads 
with  a gravity  range  from  Og  to  3g's.  Both  of  these  component  challenges  are  discussed  in  detail 
in  the  following  sections. 


INTERFACE  HEAT  EXCHANGERS 

Optimization  of  the  Orbiter  ATCS  required  advances  in  the  state-of-the-art  of  compact  heat  ex- 
changer design  and  manufacture.  In  the  areas  of  fin  density,  flow  configuration  and  headering, 
the  heat  exchanger  designs  have  gone  beyond  anything  previously  manufactured  for  the  space  program. 

The  design  of  these  heat  transfer  devices  was  approached  with  a concentrated  effort  to  minimize 
weight,  volume  and  power  impact  on  the  vehicle. 

Fin  Optimization 


Optimization  studies  concluded  that,  to  a practical  limit,  the  highest  density  design  yields  the 
lightest  and  smallest  unit.  A measure  of  the  compactness  of  a heat  exchanger,  both  from  a weight 
and  volume  standpoint,  is  the  term  (A/V),  heat  transfer  area  divided  by  core  volume.  This  term  is 
plotted  against  fin  height  and  number  of  fins  per  inch  (FPI)  In  Figure  2.1  Fin  heights  ranging 
from  0.010  to  0.200  inches  and  FPI  ranging  from  8 to  48  were  investigated.  The  obvious  conclusion 
is  that  denser  fins  yield  higher  values  of  A/V. 
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The  shorter  more  dense  fins  give  the  added  advantages  of  higher  fin  efficiency.  Improving  heat 
transfer  performance  and  the  ability  to  use  thinner  parting  sheets  reducing  weight.  Smaller  core 
sizes  also  result  in  smaller,  lighter  headers,  lighter  core  bands,  passage  closure  bars  and  mount- 
ing feet  and  less  fluid  weight. 

Prior  to  the  shuttle  program,  the  densest  fin  configuration  successfully  manufactured  by  Hamilton 
Standard  In  stainless  steel  was  a fin  height  of  0.050  In.  and  24  FPI.  After  reviewing  manufactur- 
ing limitations  It  was  concluded  that  fin  heights  as  small  as  0.020  In.  and  FPI  as  high  as  32 
could  be  manufactured  with  some  development  and  this  fin  configuration  was  selected  for  use  on  the 
orbiter.  They  resulted  In  a 55%  Improvement  In  A/V. 

In  order  to  size  and  predict  the  performance  of  heat  exchangers  with  the  selected  fin  density, 
existing  fin  data  for  Coburn  and  friction  factors  had  to  be  generalized  and  extrapolated  to  fin 
heights  40%  less  and  FPI  33%  greater  than  that  for  which  data  was  available.  A number  of  manufac- 
turing challenges  were  also  faced.  Techniques  for  manufacturing  the  dense  fin  material  were  re- 
fined. New  techniques  for  flxturlng  and  brazing  cores  were  developed.  Techniques  were  also  deve- 
loped to  seal  minute  leaks  at  closure  bars  and  between  layers  In  order  to  meet  the  extremely  low 
leakage  rate  required  by  the  Orbiter  ATCS. 

In  optimizing  a design  for  a given  set  of  requirements,  total  equivalent  weight  Including  heat  ex- 
changer, fluid  and  power  equivalent  weight  must  be  considered.  Figure  31  presents  an  example  of 
this  trade-off  for  the  Interchanger  that  cools  the  cabin  water  loops. 


FIGURE  3 INTERCHANGER  OPTIMIZATION 


In  all  cases  except  the  Hydraulics  heat  exchanger  the  optimum  fin  configuration  was  a height  of 
0.020  Inches  and  32  FPI.  Because  of  the  very  viscous  hydraulic  fluid,  that  heat  exchanger  optim- 
ized at  a fin  height  of  0.050  inches  and  32  FPI. 

Configuration  Optimization 


In  each  of  the  five  different  ATCS  applications  (coolant  loop  interfaces),  various  heat  exchanger 
system  configurations  or  arrangements  are  possible.  Two  of  the  applications  will  be  discussed  as 
examples.  Figure  4 shows  three  of  the  configurations  considered  for  the  Interchanger.  Both  the  4 
two-fluid  and  2 three-fluid  heat  exchanger  configurations  proved  to  be  heavier  In  total  equivalent 
weight  than  the  single  four-fluid  unit.  In  addition,  a single  heat  exchanger  shows  a considerable 
cost  advantage  over  multiple  heat  exchangers. 

Even  though  one  of  the  ARS  water  loops  Is  not  operating  normally,  very  little  performance  Is  lost 
In  the  four-fluid  heat  exchanger  because  of  the  way  In  which  the  layers  are  arranged.  Figure  5 
shows  this  arrangement.  Each  active  water  loop  layer  has  an  active  Freon  loop  layer  on  either 


454 


H20  #1 


H2O  #2 


-Freon  #1 
-Freon  #2 


1-4  fluid  HX 

FIGURE  4 INTERCHANGER  CANDIDATE  APPROACHES 


h2o  #1  — 

H20  #2  — 
H20  #1  — 
H20  #2  — ► 


— Freon  #1 

Pattern 

repeated 

— Freon  #2 


— Freon  #1 


— Freon  #2 


FIGURE  5 INTERCHANGER  LAYERS 


side  resulting  in  high  performance.  The  only  performance  difference  over  a two-fluid  heat  ex- 
changer is  that  the  effective  fin  height  of  the  Freon  layers  is  doubled  resulting  in  a slight  loss 
of  UA.  However,  with  the  short  fins  the  performance  degradation  is  small.  In  the  event  one  of 
the  two  Freon  loops  fails,  each  active  water  layer  still  has  an  active  Freon  layer  on  one  side  but 
must  conduct  heat  through  two  dead  layers  on  the  other  side.  Again,  because  of  the  short  fin 
height  the  performance  degradation  is  minimal  due  to  a loss  of  UA. 

The  second  example  of  a system  configuration  trade-off  Is  for  the  fuel  cell  heat  exchanger.  In 
this  case,  the  interfacing  of  five  coolant  loops  must  be  accomplished.  Figure  6 shows  the  options 
considered,  a 6 two-fluid,  3 threefluid,  and  a single  five-fluid  heat  exchanger  approach.  The 
single  five-fluid  unit  is  actually  2 four-fluid  heat  exchangers  manufactured  in  a single  stack. 
Trade-off  studies  showed  the  single  five-fluid  heat  exchanger  to  be  lightest  in  total  equivalent 
weight. 

A refinement  of  the  selected  approach  was  effected  by  building  up  the  two  heat  exchanger  cores  in 
a single  stack  making  one  unit  with  appropriate  headering.  This  again  shows  a cost  advantage  over 
multiple  units. 

A different  layer  arrangement  was  required  for  the  fuel  cell  heat  exchanger  from  that  presented 
for  the  Interchanger.  This  is  shown  in  Figure  7.  Any  one,  two  or  three  fuel  cell  loops  can  be 
effectively  cooled  by  either  or  both  Freon  loops. 
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Headering 


In  order  to  achieve  high  performance,  counterflow  within  the  heat  exchanger  core  Is  desired.  When 
flowing  four  separate  fluid  loops  through  the  same  core  efficient  headering  Is  difficult.  A novel 
combination  of  internal  and  external  headers  was  devised  that  provides  counterflow  through  most  of 
the  core.  Figure  8 presents  two  layers  of  a typical  heat  exchanger  showing  the  semicircular  ex- 
ternal headers  and  the  flow  distributing  Internal  finned  headers.  The  triangular  ends  of  the  core 
are  called  "tent  tops".  One  of  the  fluids  enters  the  core  on  the  end  of  the  tent  top,  flows  the 
length  of  the  core  and  exits  on  the  opposite  side  of  the  other  tent  top.  The  other  fluid  enters 
at  the  side  of  the  core  In  the  tent  top  area,  flows  the  length  of  the  core  In  the  other  direction 
and  exits  on  the  opposite  side.  As  can  be  seen  most  of  the  core  Is  counterflow.  The  Internal 
header  finned  sections  are  well  slotted  to  aid  In  flow  distribution.  Poor  flow  distribution  that 
adversely  affected  thermal  performance  was  observed  during  Initial  development  testing  of  an 
Interchanger.  Tolerance  studies  Indicated  that  fin  passages  near  the  edge  of  the  core  could  be 
blocked.  A computer  flow  distribution  analysis  was  conducted  that  defined  the  slotting  required 
in  the  Inlet  sections  to  properly  distribute  flow.  Subsequent  units  exhibited  no  maldistribution 
or  performance  deficiencies. 

The  final  configurations  for  the  Interchanger  and  fuel  cell  heat  exchanger  are  shown  in  the  photo- 
graphs of  Figures  9 and  10. 
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FIGURE  8 TYPICAL  HEAT  EXCHANGER 
FIN  CONFIGURATION 


FIGURE  9 FUEL  CELL  HEAT  EXCHANGER 
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FIGURE  10  INTERCHANGER 
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WATER  EVAPORATION 


Water  evaporation  was  selected  as  a heat  rejection  means  for  the  following  reasons: 

o Water  is  the  best  evaporant  from  a weight  standpoint  since  it  has  the  largest  latent  heat  of 
vaporization  of  any  candidate  fluid.  This  minimizes  the  evaporant  weight  penalty  for  cool- 
ing required  during  launch  and  an  abort  following  launch, 
o A large  quantity  of  excess  water  is  produced  by  the  fuel  cell  power  system.  Although  not 
nearly  enough  water  is  produced  for  total  heat  rejection  during  the  entire  mission,  water  is 
available  for  supplementary  heat  rejection  on-orbit  when  the  vehicle  attitude  reduces  the 
radiator  capability. 

o A water  evaporator  can  be  used  to  expel  excess  water  as  steam  when  the  water  storage  tanks 
reach  maximum  capacity.  The  steam  can  be  expelled  at  high  velocity  through  a nozzle  and 
directed  away  from  the  vehicle  to  reduce  contamination  of  the  environment  in  the  immediate 
vicinity. 

Previous  spacecraft  used  water  evaporators  for  heat  rejection.  Mercury,  Gemini  and  the  Apollo 
command  module  used  wick-feed  boilers  and  the  Lunar  Module,  Saturn  V and  Apollo  space  suit  used 
porous  plate  sublimators.  All  of  these  devices  have  response,  heat  load  range  and  life  limita- 
tions. Early  in  the  shuttle  program,  NASA  concluded  that  a new  concept  for  water  evaporation 
would  be  advantageous  and  the  flash  evaporator  evolved. 

Flash  evaporation  involves  spraying  water  on  the  walls  of  a chamber  that  is  heated  by  Freon  cool- 
ant. The  spray  chamber  is  maintained  at  a pressure  (saturation  pressure)  low  enough  for  the  water 
to  evaporate  at  a temperature  below  the  desired  Freon  outlet  temperature.  Since  a Freon  outlet 
temperature  of  40° F maximum  is  required,  the  chamber  pressure  must  be  maintained  at  or  below 
about  0.1  psia  (35°F  saturation  temperature).  In  flash  evaporation,  it  is  imperative  that  all 
of  the  water  that  reaches  the  wall  be  instantly  evaporated  to  prevent  excessive  carryover  or 
flooding  and  eventual  freezing  causing  failure  of  the  device. 

The  low  evaporation  pressure  Is  maintained  on-orbit  by  venting  the  steam  generated  overboard  to 
space  vacuum  through  a sonic  nozzle.  As  the  heat  load  Is  reduced,  the  pressure  will  fall  because 

of  reduced  steam  flow  and  may  drop  below  the  triple  point  aggravating  the  potential  freezing  sit- 

uation. 

In  the  flight  unit,  water  is  Introduced  into  the  chamber  In  a pulsing  manner  for  temperature  con- 
trol reasons.  This  causes  the  chamber  pressure  to  fluctuate  during  each  cycle  with  minimum  pres- 
sures below  the  triple  point.  A detailed  description  of  the  Flash  Evaporator  Subsystem  and  a dis- 
cussion of  its  flight  performance  are  presented  In  Reference  2 and  3 respectively. 

Because  of  the  potential  freezing  problems  and  the  ctynamlc  nature  of  flash  evaporation,  it  was 
necessary  to  perform  extensive  analyses  and  to  conduct  basic  research  on  flash  evaporation  to 

thoroughly  understand  the  process  and  aid  in  the  design  of  the  flight  system. 

Three  typical  areas  of  Investigation  concerning  the  design  and  development  of  the  flash  evaporator 
are  detailed  In  the  following  sections: 

o The  basic  research  program  conducted  at  Rice  University  to  better  understand  the  process, 
o The  analytical  effort  in  the  form  of  a thenmal  math  model  performed  during  the  design  and 
testing  phases. 

o Flash  evaporator  and  Integrated  ATCS  testing  conducted  at  NASA-JSC. 

In  addition  to  the  above,  significant  effort  was  expended  In  developing  the  desired  hollow  cone 
water  spray  distribution  and  droplet  size  distribution  and  in  analyzing  the  steam  flow  pattern  and 
velocities  within  the  evaporator  using  finite  element  techniques  to  predict  water  droplet  carry- 
over. 


FES  Description 

A brief  description  of  the  flash  evaporator  subsystem  is  in  order  before  the  details  of  its  oper- 
ating characteristics  are  discussed.  A more  detailed  description  can  be  found  in  Reference  1 and 
2. 

The  FES  (Figure  11)  contains  two  evaporators,  three  controllers  (two  primary  and  one  secondary), 
two  sets  of  feedwater  spray  valves,  nine  temperature  sensors  and  thermostatically  heated  exhaust 
steam  ducts.  Figure  12  presents  the  FES  schematic.  Freon  flows  in  two  loops  through  both  evapor- 
ators In  series  - first,  through  a "high  load"  unit,  then  through  a "topping"  unit.  Both  evapor- 
ators operate  during  launch  and  entry  but  only  the  "topper"  operates  in  orbit. 
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FIGURE  11  FLASH  EVAPORATOR  PACKAGE 


FIGURE  13  SHUTTLE  EVAPORATOR 


Each  evaporator  consists  of  three  basic  parts  made  of  aluminum  alloy:  the  evaporator  core,  the 
spray  valve/nozzle  mounting  plate,  and  the  anti -carryover  device  (ACOD).  The  cylindrical  core 
contains  the  primary  heat  transfer  surface  area.  At  one  end  of  the  core,  the  valve  plate  provides 
a heated  mounting  surface  for  the  spray  valves.  At  the  opposite  end  of  the  core,  the  anti -carry- 
over  device  aids  in  evaporating  any  water  carried  by  the  steam  flow  before  it  leaves  the  evapor- 
ator. 

In  order  to  enhance  the  evaporative  heat  transfer  area  and  water  retention,  the  internal  surfaces 
of  the  cores  are  grooved  in  an  axial  direction  as  shown  in  Figure  13.  Two  concentric  annular  fin- 
ned passages  carry  the  dual  Freon  loops  longitudinally  within  each  core  from  the  anti -carryover 
device  to  the  valve  plate  end. 

Each  valve/nozzle  assembly  contains  an  isolation  valve,  pulser  valve,  and  spray  nozzle.  The  spray 
nozzle  distributes  feedwater  over  the  evaporator  heat  transfer  surface.  The  pulser  valve  is  puls- 
ed open  for  200  msec  at  a variable  frequency  to  meter  feedwater  flow.  The  isolation  valve  pro- 
vides redundant  sealing  of  the  feedwater  line  during  quiescent  periods  and  isolation  of  the  feed- 
water  following  failure  of  a pulser. 

Three  temperature  sensors  monitor  Freon  midpoint  temperature  (between  evaporators)  and  six  monitor 
Freon  outlet  temperature.  The  three  midpoint  sensors  and  three  of  the  outlet  sensors  are  used  by 
the  control  sections  of  the  three  controllers,  and  the  remaining  three  outlet  sensors  are  used  by 
the  three  shutdown  sections  of  the  controllers. 

Once  activated,  FES  startup  and  shutoff  is  programmed  as  a function  of  midpoint  Freon  tempera- 
ture. Freon  outlet  temperature  is  maintained  within  a band  of  39  + 1°F  by  one  of  the  redundant 
primary  controllers. 

Circuitry  in  the  secondary  (abort)  controller  is  similar  to  the  primary  controllers,  except  the 
control  set  point  is  62  + 2°F. 

Each  controller  has  a shutdown  section  physically  isolated  from  the  control  section.  Each  shut- 
down section  monitors  the  performance  of  the  controller  through  a Freon  outlet  temperature  sen- 
sor. If  temperature  or  rate  of  change  limits  are  exceeded  the  FES  is  shut  down. 
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There  are  two  separate  steam  ducts.  The  high  load  duct  is  relatively  short  (7.5  ft)  with  few 
bends.  The  topping  duct  exhausts  overboard  through  two  thrust  balancing  nozzles,  one  on  each  side 
of  the  vehicle.  The  distance  from  the  evaporator  to  each  nozzle  is  approximately  21  ft. 


Basic  Research  Program 


A spray  cooling  research  program  was  initiated  by  Rice  University,  Houston,  Texas,  under  NASA 
Grant  NAS  9-65274.  Results  were  reported  to  NASA-JSC  in  three  separate  reports  during  1979  and 
also  documented  in  Reference  4. 

The  purpose  of  the  research,  summarized  in  this  section,  was  to  identify  the  fundamental  heat 
transfer  processes  involved  in  spray  cooling,  to  provide  experimental  data  useful  to  the  design 
engineer,  and  to  add  to  the  general  understanding  of  the  overall  spray  cooling  process.  Second- 
arily, the  effect  of  grooving  the  heat  transfer  surface  was  also  evaluated. 

Three  distinct  operating  modes  of  spray  cooling  have  been  identified.  The  first  is  the  case  in 
which  the  surface  vaporizes  all  of  the  impinging  spray.  This  is  called  the  "dry-wall"  state,  and 
the  heat  transfer  process  in  this  mode  is  called  "spray  evaporative  cooling".  The  second  opera- 
tional mode  is  that  in  which  the  spray  forms  a thin  liquid  film  upon  the  surface.  This  is  refer- 
red to  as  the  "flooded"  state  and  "spray  film  cooling"  is  the  name  given  to  the  associated  heat 
transfer  process.  The  third  operational  mode  is  that  in  which  the  liquid  droplets  are  deflected 
from  the  surface  by  a thin  vapor  film  which  forms  on  impact.  This  is  called  the  "Leidenfrost" 
state  and  heat  transfer.  A number  of  studies  of  these  heat  transfer  processes  has  been  reported 
in  the  literature.  A listing  of  the  references  can  be  found  in  Reference  4. 

The  research  conducted  at  Rice  was  primarily  concerned  with  the  dry -wall  state  and  with  the  tran- 
sition from  it  to  the  flooded  state.  The  crux  of  the  experimental  investigations  was  determining, 
for  spray  evaporative  cooling,  the  locus  of  flooding  points  — that  is,  determining  the  wall  tem- 
perature and  corresponding  heat  flux  at  which  the  dry -wall  to  flooding  transition  occurs.  This 
yields  the  maximum  possible  heat  flux  for  each  surface  temperature  during  dry -wall  operation. 

The  influence  of  various  parameters  upon  this  flooding  locus  was  investigated.  The  effects  of 
surrounding  pressure,  from  atmospheric  to  just  below  the  triple  point  of  water  were  studied.  The 
influence  of  a grooved  surface  compared  to  a smooth  polished  surface  was  studied.  The  influence 
of  feedwater  temperature  and  the  influence  of  an  intermittent-pulsing  spray  were  also  investigated. 

The  heat  flux  (q)  during  dry -wall  operation  is  directly  related  to  the  impinging  spray  mass  flux 
(m).  Assuming  no  superheating  of  the  departing  vapor 

q = m[X  + Cp(Ts  - T0)]  (1) 

where  X is  the  latent  heat  of  vaporization  of  the  spray  liquid,  Cp  is  its  constant  pressure 
specific  heat,  Ts  is  its  saturation  temperature,  and  T0  is  its  supply  temperature.  What  is  of 
interest  is  the  wall  temperature  (Tw)  and  corresponding  heat  flux  (q)  range  over  which  the 
dry -wall  mode  of  operation  may  exist  for  a given  spray  mass  flux. 

In  dry-wall  operation,  the  wall  temperature  and  heat  flux  adjust  so  that  all  the  impinging  spray 
evaporates  without  accumulation  on  the  surface.  If  the  surface  temperature  Is  lowered,  with  the 
spray  unchanged,  a point  is  reached  where  the  droplets  no  longer  evaporate  as  fast  as  they  arrive, 
and  liquid  will  begin  to  accumulate  on  the  surface.  This  flooding  point  is  the  lower  limit  for 
spray  evaporative  cooling  (dry-wall  mode).  The  transition  to  the  flooded  state  will  be  a gradual, 
progressive  change  when  Tw  is  greater  than  the  nucleate  boiling  temperature  T5  of  the  thin 
liquid  film.  The  transition  is  sudden,  or  catastrophic,  when  Tw  is  less  than  T^. 

Experimentally  the  two  primary  quantities  to  measure  are  the  surface  temperature  and  the  heat  flux 
through  the  metal  surface  upon  which  the  water  spray  is  impinging.  The  technique  employed  was  to 
measure  the  axial  temperature  profile  along  an  insulated  aluminum  cylinder  heated  on  one  end  and 
cooled  by  the  water  spray  on  the  other  end.  From  this  temperature  profile,  both  the  heat  flux 
through  the  surface  and  the  surface  temperature  were  readily  determined.  The  liquid  spray  was 
directed  at  the  sample  surface  from  a nozzle  located  above  the  sample;  the  mass  rate  of  Impinge- 
ment of  spray  on  the  surface  was  not  measurable.  For  a given  spray  mass  flux,  steady  state  opera- 
tion was  achieved  with  a temperature  feedback  control  circuit  to  adjust  electrical  power  to  the 
heater.  The  entire  assembly  was  placed  In  a bell  jar  in  which  the  pressure  was  controlled  by  ex- 
hausting through  an  orifice  to  a liquid  nitrogen  cold  trap  by  means  of  a vacuum  pump. 

Beginning  with  the  surface  in  a dry -wall  state,  the  set  point  to  the  temperature  controller  was 
lowered  gradually  until  the  surface  just  began  to  flood.  At  this  point  data  was  recorded.  It 
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should  be  noted  that  "flooding"  was  a subjective  visual  determination  based  upon  the  experi- 
menter's evaluation  that  the  surface  was  just  on  the  verge  of  flooding,  small  pools  just  beginning 
to  form.  For  the  smooth  polished  surface  this  was  fairly  straight  forward.  For  the  grooved  sur- 
face, however,  flooding  was  a bit  more  difficult  to  define.  It  was  chosen  as  the  point  where  some 
water  could  be  standing  in  the  grooves,  but  never  enough  to  allow  spanning  of  the  grooves. 

Using  distilled  water  at  25° C sprayed  from  a 0.40  mm  dia.,  90°  included  angle,  full -cone  noz- 
zle located  approximately  45  cm  above  the  surface,  the  flooding  locus  was  determined  for  a smooth 
6061 -T6  aluminum  surface  at  atmospheric  pressure,  and  at  average  pressures  of  about  19,  6.76,  and 
4.56  mmHg.  These  flooding  locus  curves  are  shown  in  Figure  14  (data  points  have  been  eliminated 
for  clarity). 


For  a grooved  aluminum  surface,  the  flooding  locus  was  determined  at  atmospheric  pressure,  and 
average  pressures  of  about  20.18,  7.11,  and  4.51  mmHg.  It  was  found  that  grooves  on  the  surface 
had  no  apparent  effect  on  the  flooding  locus  or  dry -wall  operation.  However,  based  on  testing 
conducted  at  Hamilton  Standard,  grooves  do  improve  water  retention  and  help  spread  unevaporated 
water  to  less  stressed  areas  in  a flight  evaporator  configuration. 

Knowledge  of  the  flooding  locus  is  particularly  important  for  operation  at  pressures  below  the 
triple  point  of  water  (4.587  mmHg).  At  such  pressures,  excess  water  on  the  surface  creates  the 
potential  for  freezing.  For  both  surfaces  studied,  at  pressures  below  the  triple  point,  it  was 
observed  that  for  values  of  Tw  - Ts  less  than  about  15°C,  freezing  would  begin  at  the  inter- 
face of  the  heated  surface  and  the  surrounding  Teflon  insulation  (the  coolest  points  on  the  sur- 
face). The  ice  formation  then  moved  rapidly  inward  above  the  surface  and  formed  an  ice  cap  over 
the  entire  surface.  Once  formed,  increasing  the  heating  rate  through  the  surface  would  not  stop 
the  ice  growth  (the  surface  just  got  hotter).  The  only  way  to  halt  the  growth  of  the  ice  cap  was 
to  raise  the  pressure  to  a value  above  the  triple  point.  On  doing  so,  melting  began  immediately. 
Increasing  the  pressure  proved  to  be  the  only  effective  means  of  controlling  ice  formation.  A 
procedure  for  doing  this  on  the  flight  unit  was  developed  during  testing  at  NASA-JSC. 

Water  freezing  and  accumulating  on  poorly  heated  surfaces  was  also  experienced  on  the  flight  con- 
figuration evaporator.  Great  care  was  exercised  in  the  design  of  the  core  to  assure  that  all 
areas  receiving  spray  would  be  heated  sufficiently  to  prevent  ice  formation. 

Testing  was  conducted  using  a pulsing-intermittent  rather  than  a steady  state  spray  at  low  pres- 
sure. A nozzle  with  a solenoid  valve  was  operated  with  a fixed  "on-time"  of  200  msec  and  an 
on-off  pulsing  frequency  variable  between  0 and  4 hz,  thus  allowing  the  spray  "duty  cycle"  to  be 
varied. Tests  were  run  at  7.11  mmHg  and  at  atmospheric  pressure.  Attempts  were  made  to  operate  at 
pressures  below  the  triple  point,  but  at  these  low  pressures  the  accumulation  of  water  on  the  noz- 
zle negated  proper  spray  operation.  This  accumulation  of  water  on  the  nozzle  at  very  low  pres- 
sures is  thought  to  be  associated  with  solenoid  operating  in  the  nozzle;  it  was  not  observed  at 
pressures  above  the  triple  point  or  for  continuous  operation.  A great  deal  of  development  effort 
was  spent  on  the  flight  configuration  spray  valves  to  reduce  the  valve  "dribble  volume"  and  pre- 
vent valve  freezing. 

The  results  obtained  suggest  that  with  pulsing  duty,  the  spray  evaporative  cooling  process  is  not 
basically  different  from  that  with  continuous  duty.  The  flooding  locus  is  the  same  in  either 
case;  it  occurs,  for  a given  wall  temperature,  at  a heat  flux  lower  than  continuous  duty  by  the 
ratio  of  the  duty  cycle  of  the  pulsing  spray. 
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A number  of  measurements  were  attempted  at  low  pressures  using  feedwater  at  temperatures  greater 
than  25°C.  It  was  found  that  for  water  temperature  greater  than  about  40°C,  the  water  drop- 
lets leaving  the  nozzle  "instantaneously"  evaporated  — flash  evaporation  --  particularly  in  the 
interior  of  the  spray.  The  large  vapor  plume  so  formed  negated  a reasonably  steady  spray  reaching 
the  heated  surface  in  the  apparatus  used.  It  was  concluded  that  for  a given  system  operating 
pressure,  there  is  an  upper  limit  on  the  feedwater  temperature  above  which  the  effectiveness  of 
the  spray  evaporative  cooling  process  is  negated  because  of  the  spray  flashing  directly  to  vapor 
before  reaching  the  surface  to  be  cooled. 

All  of  the  flooding  locus  data  obtained  in  the  experiments  at  Rice  University  may  be  summarized, 
as  shown  in  Figure  15,  by  defining  a "flooding  coefficient" 

h*  = q*/(Tflood  - Ts)  (2) 

which  is  simply  the  slope  of  each  flooding  locus,  and  is  dependent  upon  the  operating  pressure,  or 
perhaps  more  conveniently  the  saturation  temperature  of  the  liquid  spray.  For  the  designer,  the 
variable  of  interest  is  the  wall  temperature  Tw  rather  than  (Tw  - Ts).  Figure  15  could  be 
used  to  determine  the  best  operating  pressure  (saturation  temperature)  to  yield  the  largest  at- 
tainable heat  flux  without  flooding. 


FIGURE  15  FLOODING  COEFFICIENT 


The  linear  flooding  loci  determined  experimentally  suggest  that  a conduction-controlled  droplet 
evaporation  model  might  serve  as  an  adequate  analytical  model  for  predicting  the  flooding  coeffi- 
cient h*.  Such  a model  was  developed  and  documented  in  reports  to  NASA-JSC  under  the  previously 
mentioned  NASA  grant.  Agreement  of  the  analytical  results  for  atmospheric  pressure  with  those  ob- 
tained from  experiment  are  close  enough  to  give  confidence  in  the  model  and  suggest  that  further 
study  might  yield  fruitful  results. 


FES  Thermal  Model 


A computer  model  of  the  FES  was  written  to  study  and  predict  its  dynamic  behavior.  This  model  in- 
cludes the  effects  of  water  spray  distribution  on  the  core  walls,  dual  Freon  loops  at  varying 
inlet  conditions,  cyclic  steam  pressure  resulting  from  a pulsing  water  spray  and  steam  exhaust 
duct  flow  characteristics  and  the  control  laws  that  modulate  spray  pulsing  to  control  Freon  outlet 
temperature.  The  highly  dynamic  nature  of  the  FES  results  from  the  short  200  millisecond  pulses 
of  water  sprayed  onto  the  core  at  controlled  intervals  and  the  low  thermal  inertia  of  the  evapora- 
tor. These  pulses  of  water  are  rapidly  evaporated  upon  contacting  the  hot  core  walls  heated  by 
the  Freon.  Steam  pressure  quickly  builds  up  in  the  core  as  the  water  evaporates  and  then  rapidly 
decays  as  the  pulse  of  water  spray  ends  and  the  steam  exits  from  the  duct.  In  the  subsystem,  the 
important  dynamic  parameters  are  the  Freon  temperatures,  the  amount  of  water  sprayed  into  the  core 
and  evaporated,  the  steam  pressure  in  the  core,  and  the  controller  signals  to  modulate  the  short 
200  millisecond  pulses  of  water. 

Freon  temperatures  are  calculated  throughout  the  subsystem.  The  evaporator  itself  is  divided  into 
an  Anti -Carryover  Device  (ACOD)  zone,  a core  wall  zone,  and  a valve  plate  zone  as  shown  in  Figure 
16.  In  the  evaporator  core  wall  zone  where  the  temperature  distribution  is  crucial  to  determine 
the  amount  of  water  evaporation,  as  fine  a division  of  the  core  wall  into  segments  as  desired  can 
be  made.  Figure  17  shows  one  of  these  segments  as  used  in  the  computer  model.  Any  loss  of  heat 
from  the  Freon  to  the  core  wall  results  in  a decrease  in  Freon  temperature;  this  is  modeled  for 
each  Freon  segment  by  applying  the  First  Law  of  Thermodyanmics  as  follows: 

MftDCpf  dTf(i)  = mfCpf[Tf1n(i)-Tf0Ut(i)]-hfA(i)[Tf(i)-Tw(i)]  (3) 
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FIGURE  17  THERMAL  MODEL 


A similar  energy  balance  is  applied  to  the  evaporator  core  wall  whereby  its  temperature  changes 
whenever  an  unbalance  exists  between  the  heat  input  from  the  Freon  and  the  heat  loss  to  the  imping- 
ing water  spray: 

Mw(i )Cpw  dTw(i)  = C[Tw(1-l)-Tw(1)]-C[Tw(1)-Tw(1+l)]-Qe(1)+hf  A(1 )[Tf (1 )-Tw(i ) ] (4) 


The  thermodynamics  and  heat  transfer  on  the  water  spray  Is  the  most  dynamic  and  the  most 
challenging  to  model.  The  water  leaving  the  nozzle  impinges  on  the  various  zones  and  segments  of 
the  core  in  different  amounts.  This  distribution  varies  with  feedwater  temperature  and  pressure 
and  Is  different  for  the  high  load  and  topping  evaporators.  A spray  distribution  factor  was 
defined  and  correlated  to  test  data  to  arrive  at  the  following  expression  which  gives  the  general 
shape  of  all  spray  distributions: 

f(?)  = 0.5  £l  + tanh[m(*  - <t>)]}  (5) 

The  factors  <|>  and  m are  functions  of  feedwater  temperature  and  pressure.  A typical  cumulative 
spray  distribution  is  shown  in  Figure  18. 


FIGURE  18  SPRAY  DISTRIBUTION 


462 


The  water  impinging  on  a segment  of  the  core  is  then  evaporated  at  a rate  dependent  upon  the  dif- 
ference in  temperature  between  the  wall  and  the  temperature  of  the  steam  in  the  core.  The  tempe- 
rature of  the  steam  is  at  the  saturation  temperature  corresponding  to  the  pressure  in  the  core. 
As  the  steam  evaporates,  the  pressure  and  therefore  the  temperature  rises  in  the  core  until  the 
spray  stops.  Then,  the  pressure  and  temperature  decrease  as  the  steam  exits  the  core.  Steam 
pressure  is  a function  of  the  flow  characteristics  of  the  exhaust  duct  system.  Depending  on  the 
rate  of  evaporation,  all  the  water  impinging  on  the  core  may  not  evaporate  before  the  beginning  of 
the  next  spray  pulse.  The  division  of  the  core  into  segments  permits  the  calculation  of  the  pre- 
cise spot  where  this  buildup  of  water  may  occur.  Division  of  the  core  into  fewer  segments  would 
average  over  this  spot  and  would  not  predict  any  water  buildup  when  there  actually  may  be  one. 
This  highly  dynamic  rising  and  falling  of  the  steam  temperature  and  pressure  is  therefore  coupled 
in  the  model  with  the  spray  and  wall  temperature  distributions  to  determine  the  amount  of  imping- 
ing spray  that  is  evaporated  in  the  core  and  thereby  the  heat  removed  from  the  Freon. 

The  pulsing  of  the  spray  is  regulated  by  the  controller  to  cool  the  freon  to  an  outlet  temperature 
of  39° F.  To  model  the  controller,  the  actual  electronic  circuitry  was  analyzed.  As  in  the  con- 
troller, the  computer  model  translates  the  incoming  temperatures  into  voltages  and  applies  the 
control  laws.  The  control  includes  a combination  of  proportional,  integral  and  differential  gains 
with  lead-lag  compensation.  When  the  control  law  output  voltage  reaches  six  volts,  a 200  milli- 
second spray  pulse  is  initiated;  and  the  control  law  output  voltage  Is  reset  to  zero.  In  addition 
to  the  control  laws,  the  shutdown  logic  and  the  control  laws  for  the  secondary  controller  are  in- 
cluded in  the  computer  model. 

Modelling  the  Flash  Evaporator  Subsystem  on  a digital  computer  presented  a major  technical  chal- 
lenge. More  than  twenty  simultaneous  partial  differential  equations  with  time  constants  sometimes 
orders  of  magnitude  different  had  to  be  solved.  The  Gear  Method,5  which  is  a multi  step  predic- 
tor corrector  method  whose  order  and  time  increments  are  automatically  chosen  as  the  integration 
proceeds,  was  used  effectively  to  produce  computer  running  times  as  low  as  1/3  of  real  time. 

In  spite  of  the  inherent  difficulty  in  modelling  the  highly  dynamic  FES,  the  computer  program  has 
been  used  successfully  to  predict  test  data,  to  establish  acceptance  criteria  for  controller  oper- 
ation, and  to  simulate  ground  test  and  flight  operation. 

FES  Testing 


The  FES  presented  a performance  verification  challenge.  Because  of  the  size  of  the  steam  exhaust 
ducting,  the  actual  flight  configuration  could  not  be  tested  at  a commercial  facility.  FES  per- 
formance testing  was  conducted  using  a duct  simulator.  The  simulator  consisted  of  a short  duct 
section,  a large  diameter  volume  and  adjustable  exit  orifice.  The  large  volume  was  necessary  to 
simulate  the  volume  of  the  flight  duct  configuration.  The  orifice  was  adjusted  to  give  the  same 
steady  state  evaporator  pressure  as  the  flight  configuration  when  operated  in  the  Hamilton  Stan- 
dard chamber.  Chamber  pressure  could  not  be  maintained  at  space  vacuum  levels  and  reached  1 mmHg 
at  maximum  steam  flow. 

In  order  to  fully  qualify  the  FES  for  flight,  it  was  deemed  necessary  to  test  the  flight  configu- 
ration under  expected  flight  conditions.  Two  series  of  tests  were  conducted  in  the  Space  Environ- 
mental Simulation  Laboratory  (SESL)  at  NASA-JSC.  It  was  necessary  to  use  the  large  chamber  A for 
these  tests. 

The  first  series  of  tests  (OFEST)  was  conducted  with  a flight  configuration  FES  as  the  only  test 
hardware.  Testing  included: 

o Simulated  launch  and  entry  ambient  pressure  transients, 
o Simulated  Freon  inlet  temperature  transients, 
o Steady  state  performance  limits. 

o Testing  to  help  size  the  orifice  in  the  duct  simulator  used  at  Hamilton  Standard, 
o Steam  exhaust  plume  evaluation. 

The  second  series  of  tests  (Integrated  ATCS  Tests)  was  conducted  with  a flight  configuration  FES 
plus  additional  ATCS  hardware,  including  a space  radiator  panel,  in  an  integrated  system  test. 
Testing  included: 

o Actual  system  transient  performance 
o Evaluation  of  failure  conditions 
o Radiator  panel  performance 

A major  accomplishment  of  the  testing  relative  to  the  FES  was  the  establishment  of  a cleanout  or 
thawing  procedure  in  the  unlikely  event  of  a freeze-up  on-orbit.  Following  the  intentional  flood- 
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ing  of  the  evaporator,  the  secondary  controller  that  controls  Freon  outlet  temperature  to  62° F 
was  used  to  raise  the  evaporator  steam  pressure  above  the  triple  point.  Under  these  conditions, 
thawing  of  Ice  accumulated  In  the  core  occurred  quite  rapidly  and  completely. 

CONCLUSIONS 


The  major  ATCS  challenges  were  met  using  a combination  of  established  system  engineering  techni- 
ques, basic  research,  sophisticated  analytical  techniques  and  extraordinary  testing.  In  the  pro- 
cess, advances  in  the  state-of-the-art  of  heat  exchanger  design  and  manufacture  were  effected. 
These  advances  resulted  in  significant  weight  and  particularly  volume  reductions  over  what  were 
previously  typical  spacecraft  heat  exchanger  configurations.  In  order  to  realize  these  gains,  it 
was  necessary  to  perform  extensive  system  level  optimization  trade-off  studies,  extrapolate  exist- 
ing sizing  techniques  to  much  denser  fin  configurations  and  develop  improved  manufacturing  techni- 
ques. All  of  the  heat  exchangers  in  the  ATCS  met  or  exceeded  predicted  performance  during  ground 
test  and  flight. 

Flash  evaporation  at  pressures  below  the  triple  point  had  never  been  attempted  previously  in 
spacecraft  heat  rejection.  In  fact,  it  was  not  a well  understood  process.  A system,  based  on 
basic  flash  evaporation  research  and  extensive  analytical  modeling,  was  developed  that  met  all  of 
the  high  response,  high  heat  load  range  and  long  life  requirements  of  the  orbiter.  The  FES  also 
can  be  considered  an  advance  in  the  state-of-the-art  in  spacecraft  expendable  heat  rejection. 
During  the  development  process,  basic  knowledge  of  the  spray  evaporation  process  and  how  to  con- 
trol it  was  gained.  With  the  exception  of  some  minor  temperature  sensor  anomalies  on  the  first 
two  shuttle  flights,  the  FES  has  performed  flawlessly. 
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ABSTRACT 

Development  of  the  Space  Shuttle  orbiter  environmental  control  and  life  support  system  (ECLSS)  included  the  identification  and  resolution 
of  several  interesting  problems  in  several  systems.  Some  of  these  problems  occurred  late  in  the  program,  including  the  flight  phase.  This  paper  ad- 
dresses problems  and  solutions  related  to  the  ammonia  boiler  system  (ABS),  smoke  detector,  water/hydrogen  separator,  and  waste  collector 
system  (WCS). 

ABS  problems  were  concerned  with: 

• Inducing  vortex  flow  in  the  heat  exchanger  to  improve  heat  transfer 

• Accumulating  contamination  from  ammonia  as  a result  of  evaporation  in  the  heat  exchanger 

• Excessive  carbon  content,  which  developed  while  redrawing  tubes  to  size  resulting  in  corrosion  and  leakage 

• Slower  control  system  response  to  changes  in  temperature  as  a result  of  redesign  to  inhibit  moisture  entering  the  outlet  temperature 
sensors 

Smoke  detector  problems  and  solutions  resulted  in: 

• Changing  from  a quartz  crystal  microbalance  (QCM)  sensing  concept  to  an  ionization  sensor 

• Understanding  ion  sensor  operation  during  altitude  changes 

• Changing  air  pump  design 

• Revising  pump  motor  design 

• Modifying  electronics  hybrid  design 
Water/hydrogen  separator  problems  and  challenges  included: 

• Revising  flow  path  lengths  to  meet  pressure  drop  requirements 

• Increasing  H2  removal  efficiency  by  adding  flow  turbulators 

• Techniques  of  welding  tubes  into  a thin  header  plate 

• Bundling  of  tubes  to  withstand  shock  and  vibration  environments 

Waste  collector  system  problems  encountered  and  resolved  during  the  orbiter  flight  test  program  involved: 

• Restraint  systems 

• Last  drop  of  urination  removal 

• Urine  cap  evaluation 
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AMMONIA  BOILER  SYSTEM 


During  the  Space  Shuttle  orbiter  entry  mission  phase  at  altitudes  below  120,000  feet,  the  ammonia  boiler  system  (ABS)  provides  a means  for 
rejecting  waste  heat  loads  into  the  atmosphere.  The  ABS  also  provides  cooling  on  the  ground  between  postlanding  but  before  the  ground  support 
cooling  equipment  is  connected.  Heat  loads  generated  by  Shuttle  orbiter  systems  are  transported  within  the  vehicle  by  two  separate  and  indepen- 
dent Freon  21  loops.  When  the  ABS  is  operating,  heat  is  transferred  from  the  Freon  21  by  evaporation  of  anhydrous  ammonia,  which  is  then 
vented  overboard.  The  ABS  is  a completely  self-contained  system  that  uses  a small  amount  of  electrical  power  as  its  only  outside  supply  require- 
ment, and  can  transfer  heat  at  a rate  in  excess  of  120,000  Btu’s  per  hour. 


HEAT  EXCHANGER  DESCRIPTION 

The  ABS  heat  exchanger  consists  of  four  separate  shell-and-tube  modules.  Figure  1 shows  the  tube  bundle  used  in  each  module,  the  internal 
baffles,  and  the  tube  sheets.  Each  bundle  contains  77  tubes  that  have  an  outside  diameter  of  0.093  inch  and  transport  the  ammonia  internally. 
Each  tube  expands  into  each  of  the  baffles  to  prevent  flow  bypass  and  to  secure  the  tubes  during  vibration.  The  tubes  are  brazed  into  the  tube 
sheets  and  the  tube  sheets  are  brazed  into  the  shell  to  form  a module.  The  Freon  21  makes  five  passes  through  the  tube  bundle  in  each  module. 
Each  of  the  tubes  in  the  two  ammonia  outlet  modules  contains  a spinner,  which  is  a twisted  metal  ribbon  divider  that  forms  two  spiral  paths  to  im- 
part a vortex-like  flow  to  the  ammonia  in  order  to  help  increase  the  rate  of  heat  transfer.  The  ammonia  circuit,  which  consists  of  two  modules,  was 
sized  to  bring  the  superheated  ammonia  exhaust  gas  to  within  10  °F  of  the  inlet  Freon  temperature.  All  of  the  heat  exchanger  parts  are  fabricated 
from  stainless  steel  and  either  brazing  or  welding  is  used  to  join  parts  in  order  to  minimize  weight. 


FIGURE  1.  HEA  T EXCHANGER  MODULE  TUBE  BUNDLE 


HEAT  EXCHANGER  DEVELOPMENT  TESTING 

In  order  to  confirm  the  heat  transfer  and  pressure  drop  characteristics  of  the  heat  exchanger,  a simplified  development  unit  was  built  early  in 
the  program.  The  unit  consisted  of  two  modules  welded  together  with  one  counterflow  Freon  circuit.  This  configuration  would  normally  be  used 
to  cool  a single  Freon  loop.  At  the  ammonia  exit  there  was  a long  duct  containing  a bundle  of  77  spinners  that  could  be  inserted  into  various  posi- 
tions in  the  ammonia  tubes.  The  spinner  was  fabricated  by  twisting  a flat  piece  of  stainless  steel  to  form  a helix  with  about  six  turns  per  inch. 


During  the  design  phase,  it  was  believed  that  the  spinners  would  improve  the  low  velocity  heat  transfer  rate  at  the  ammonia  inlet  end  of  the 
tubes  by  rotating  the  flow  and  throwing  liquid  droplets  outward  to  the  warmer  tube  wall.  Initial  test  results  were  unusual  and  it  was  quickly  deter- 
mined that  the  best  heat  exchanger  performance  was  achieved  when  the  spinners  were  located  in  the  downstream  portion  of  the  tubes  where  the 
ammonia  was  being  superheated.  Figure  2 shows  some  of  the  test  data  and  the  final  spinner  placement.  When  the  spinners  were  inserted  further 
upstream  into  the  mixed  (vapor/liquid)  region,  the  liquid  droplets  probably  gathered  toward  the  center  of  the  spinners  and  traveled  down  without 
the  normal  boiling  that  would  occur  when  the  liquid  droplets  contact  the  tube  wall.  The  result  was  a loss  of  superheat  in  the  ammonia  discharge 
and  a reduction  in  heat  exchanger  effectiveness. 
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LENGTH  OF  SPINNER  INSERTION  FROM  AMMONIA  OUTLET  (%) 


FIGURE  2.  EFFECT  OF  SPINNER  LOCA  TION  ON  PERFORMANCE 


HEAT  EXCHANGER  CONTAMINATION 

During  development  testing  of  the  full-size  heat  exchanger  with  the  spinners  correctly  placed,  a loss  in  superheat  was  observed  with  some 
cold  liquid  ammonia  droplets  in  the  exhaust  after  considerable  operating  time.  The  degradation  in  performance,  which  resulted  in  an  increase  in 
ammonia  flow  rate  to  absorb  the  required  heat  load,  was  caused  by  the  accumulation  of  oil  in  the  ammonia  tubes.  A clean  heat  exchanger  will 
transfer  about  90  percent  of  the  total  heat  load  in  the  upstream  module,  but  after  only  about  2 hours  of  operation,  the  heat  transfer  in  the 
upstream  module  would  be  about  the  same  as  in  the  downstream  module.  It  was  apparent  that  the  transition  to  dry  vapor,  which  separated  the 
boiling  and  superheat  regions  in  the  heat  exchanger,  was  moving  down  the  ammonia  tubes  toward  the  exit  with  operating  time.  After  about  10 
hours  of  operation,  the  ammonia  side  of  the  heat  exchanger  was  flushed  with  a solvent.  Analysis  of  the  nonvolatile  solvent  residue  disclosed  that  it 
contained  4 to  5 cubic  centimeters  of  oil.  Subsequent  heat  exchanger  flushing  operations  that  were  performed  after  operating  periods  in  excess  of 
10  hours  indicated  that  a self-cleaning  process  limited  the  amount  of  oil  that  could  accumulate. 

After  noticing  the  accumulation  of  oil  in  the  heat  exchanger,  the  oil  content  in  the  ammonia  was  monitored.  Although  the  ammonia  procure- 
ment specification  required  a 5-ppm  maximum  oil  content  and  the  supplier  certified  that  the  ammonia  conformed  to  the  specification,  actual 
analysis  showed  approximately  a 30-ppm  content.  An  investigation  of  ammonia  manufacturing,  storage,  and  delivery  systems  revealed  that  the 
5-ppm  oil  content  limitation  is  not  realistic  for  ABS  operation.  A 10-ppm  limit  appears  to  be  more  practical,  but  it  is  anticipated  that  periodic 
flushing  of  the  heat  exchanger  will  still  be  necessary  for  removing  oil  accumulation  and  restoring  the  desired  heat  transfer  effectiveness  level; 
however,  instead  of  specifying  a fixed  operating  time  interval  between  flushing  operations,  the  need  for  such  cleaning  on  the  orbiter  will  be 
established  by  monitoring  the  ammonia  vapor  discharge  temperature  to  detect  loss  of  superheat. 


CORROSION  OF  HEAT  EXCHANGER  TUBING 

At  the  conclusion  of  the  qualification  test  program,  it  was  determined  that  there  was  excessive  leakage  from  the  Freon  side  to  the  ammonia 
side  of  the  heat  exchanger.  The  areas  were  located  that  were  leaking  and  metallurgical  examination  with  a scanning  electron  microscope  revealed  a 
pitting  corrosion  attack  on  the  stainless  steel  3/32-inch  diameter  tubing.  In  the  leaking  areas,  the  corrosion  had  progressed  through  the  0.008-inch 
thick  tubing  wall. 

Tubing  for  the  development  heat  exchanger  and  for  the  assembly  installed  on  Orbiter  101  for  the  approach  and  landing  test  program  had 
been  specified  to  be  made  from  347  CRES  material.  But  delivery  schedule  problems  caused  a change  to  304L  CRES  material  to  meet  the  manufac- 
turing schedules  for  the  test  heat  exchanger. 
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Although  the  specification  for  this  material  allows  a maximum  carbon  content  of  0.03  percent,  chemical  analysis  of  tubes  showed  that  the 
actual  carbon  content  was  about  0.07  percent.  The  use  of  304  series  stainless  steel  with  a carbon  content  greater  than  0.03  percent  is  not 
recommended  for  brazing  because  of  carbide  precipitation,  which  occurs  during  cooling  and  results  in  a loss  of  corrosion  resistance. 


Since  it  was  suspected  that  the  tubing  vendor  had  used  the  wrong  material  to  redraw  the  tubing  to  its  proper  final  size,  additional  tubing  was 
ordered  from  a different  vendor.  This  time,  several  samples  were  chemically  analyzed  prior  to  redrawing  and  found  to  have  a carbon  content  of 
about  0.025  percent.  After  redrawing,  chemical  analysis  of  several  samples  showed  a carbon  content  of  about  0.07  percent. 

Redrawing  of  the  tubing  to  the  proper  final  size  (3/32-inch  outer  diameter,  0.008-inch  wall  thickness)  requires  multiple  draws.  Typically, 
hydrocarbon  greases  are  used  to  help  draw  the  tube  through  the  dies.  After  each  draw,  the  tubing  is  cleaned  and  annealed  to  soften  the  material 
prior  to  the  next  draw.  As  the  tubing  diameter  becomes  smaller,  cleaning  the  grease  from  the  tubing  becomes  more  difficult.  Apparently,  the  small 
residue  of  hydrocarbon  grease  that  remained  in  the  tubing  after  cleaning  resulted  in  carburization  of  the  tubing  during  the  annealing  process. 


In  order  to  prevent  the  carburization  from  recurring,  two  changes  were  made.  First,  after  conducting  an  industry  survey  to  determine  prac- 
tical tube  cleaning  procedures,  a detailed  procedure  was  prepared.  Second,  the  tube  material  was  changed  back  from  304L  CRES  to  347  CRES. 
Although  the  347  CRES  can  also  be  carburized,  substantial  amounts  of  stabilizing  elements  (columbium  and  tantalum)  make  carbide  precipitation 
less  likely  if  a small  amount  of  carburization  takes  place.  Additional  tubing  was  procured  from  a vendor  who  followed  the  recommended  cleaning 
procedure.  Samples  taken  before  and  after  redrawing  showed  that  no  carburization  had  taken  place  and  subsequent  usage  of  this  tubing  has  been 
successful. 


TEMPERATURE  SENSOR  MOISTURE  PROBLEM 


Each  Freon  outlet  loop  has  three  surface-mounted  platinum  resistance  temperature  sensors  to  maintain  the  outlet  temperature  at  a nominal 
35  °F,  based  on  a change  in  sensor  resistance  with  changes  in  temperature.  One  sensor  controls  temperature  through  the  primary  control  system. 
The  second  sensor  controls  temperature  through  the  secondary  control  system,  which  duplicates  the  primary  control  system  and  is  used  only  in  the 
event  of  a primary  control  system  failure.  The  third  sensor  is  monitored  by  circuitry  that  switches  control  from  the  primary  to  the  secondary  con- 
trol system  if  the  Freon  outlet  temperature  is  excessively  low  for  an  extended  period  of  time.  All  three  sensors  are  identical  in  design  and  each  is 
surface-mounted  on  the  Freon  line.  The  mounting  surface  of  each  sensor  is  coated  with  a thin  film  of  thermal  conducting  grease  to  provide  quick 
response  from  the  sensor  to  changes  in  Freon  temperature. 


After  the  qualification  test  program  during  field  operation,  there  were  several  temperature  sensor  failures.  These  failures  were  caused  by 
moisture  penetration  into  the  porous  ceramic  insulating  material  between  the  platinum  element  and  the  metal-mounting  baseplate.  The  ceramic  ex- 
hibited very  high  bulk  electrical  resistivity  when  dry,  but  this  resistance  dropped  rapidly  when  the  smallest  amount  of  moisture  was  absorbed. 


The  sensor  assembly  incorporates  a fiberglass-reinforced  silicone  rubber  cover  to  seal  the  platinum  element  from  the  ambient  environment. 
Water  immersion  testing  performed  on  this  design  showed  a rapid  degradation  in  insulation  resistance  between  the  element  and  the  mounting  base. 
Impregnation  of  the  rubber  cover  with  a silicone  gel,  which  was  previously  used  for  moisture  resistance  in  similar  applications,  decreased  the  rate 
of  moisture  penetration  through  the  cover,  but  the  bond  between  the  rubber  cover  and  the  silver  baseplate  was  not  an  adequate  moisture  seal. 
Attempts  to  improve  this  bond  by  roughening  the  silver  plate  surface  and  adding  room  temperature  vulcanized  (RTV)  type  silicone  rubber  were 
not  successful. 


In  order  to  provide  adequate  resistance  to  moisture  penetration,  it  was  decided  that  the  rubber  cover  should  be  replaced  by  a thin  metal  cover 
and  soldered  to  the  baseplate  with  multiple  rubber  seals  where  the  lead  wires  extend  through  the  cover.  Because  of  the  additional  mass  of  the  metal 
cover,  it  was  anticipated  that  the  time  response  of  the  sensor  to  temperature  changes  might  be  longer,  and,  therefore,  result  in  system  instability. 
Water  immersion  testing  of  this  configuration  showed  no  significant  loss  in  insulation  resistance  after  an  extensive  length  of  time;  however,  the 
results  of  system  response  testing  were  somewhat  surprising.  Although  the  response  of  the  sensor  was  slower,  there  was  no  apparent  effect  on 
system  stability.  Instead,  the  slower  response  of  the  primary  control  sensor  (RTj)  resulted  in  a longer  temperature  undershoot  during  start  up. 
This  increased  time,  monitored  by  the  control  transfer  (RT3)  sensor,  resulted  in  a transfer  of  control  from  the  primary  to  the  secondary  system. 


In  order  to  solve  this  problem,  the  length  of  time  required  to  transfer  from  primary  to  secondary  control  could  have  been  increased,  but  this 
would  have  required  an  expensive  change  in  the  electronic  controls.  Instead,  the  thermal  conducting  grease  under  the  RT3  sensor  was  replaced  by  a 
silicone  grease  with  a much  lower  thermal  conductivity.  The  effect  was  to  further  slow  down  the  time  response  of  the  RT3  sensor  to  compensate 
for  the  slower  time  response  of  the  RTj  and  RT2  sensors. 
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SMOKE  DETECTOR 


Brunswick  fire  detectors  are  used  in  the  avionics  bay  enclosures  and  the  crew  compartment  in  conjunction  with  a Halon  suppression  system 
to  provide  early  warning  and  contain  any  potential  hazards.  Figure  3 shows  their  locations.  To  better  understand  the  design  problems  and  how 
they  were  solved,  a brief  description  of  the  detector  operation  follows. 


This  device  is  an  active  instead  of  a passive  ionization  detector  and  continuously  samples  the  surrounding  air  for  detection  of  submicron 
pyrolitic  matter,  which  is  associated  with  the  early  (incipient)  stage  of  fire.  Figure  4 shows  a sectional  view  of  the  unit.  The  sample  air  flow  drawn 
into  the  detector  is  divided  between  two  paths:  one  goes  through  the  ionization  sensing  chamber  and  the  other  bypasses  the  chamber  and  goes 
directly  to  a rotary  vane  positive  displacement  pump.  The  pump  is  driven  by  an  ac  synchronous  motor  powered  by  a 28  Vdc  dc-to-ac  converter 
motor  controller  hybrid. 


The  two-path  air  flow  scheme  provides  for  aerodynamic  separation  of  particles  entering  the  unit  and  prevents  all  large  particles  not 
associated  with  a hazard  from  entering  the  sensor  and  creating  false  alarms.  Submicron  particles  in  the  air  sample  combine  with  charged  particles 
created  by  a radioactive  source  of  Americium  241,  which  reduces  the  ion  current  produced  within  the  ionization  chamber.  The  resulting  change  in 
current  is  proportional  to  the  concentration  of  particles.  This  current  is  converted  to  a voltage  through  a high  impedance  resistor  network,  and  is 
processed  through  a voltage-to-frequency  converter  hybrid  for  evaluation  by  a large-scale  integrated  circuit  (LSI).  The  LSI  measures  the  frequency 
and  rate  of  change  and  triggers  an  alarm  signal  when  the  appropriate  threshold  values  are  reached. 


9 SMOKE  DETECTOR  ASSEMBLIES 


3 EXTINGUISHER  ASSEMBLIES 
1 IN  EACH  OF  3 AVIONICS  BAYS 


2 IN  EACH  OF  3 AVIONICS  BAYS 
2 IN  THE  FLIGHT  DECK  CREW 
COMPARTMENT 

1 IN  THE  LIFE  SUPPORT  EQUIPMENT 
COMPARTMENT 


FIGURE  3.  SPACE  SHUTTLE  ORBITER  FIRE  PROTECTION  SYSTEM 
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FIGURE  4.  SMOKE  DETECTOR  AIR  FLOW  DIAGRAM 


DESIGN  PROBLEMS  AND  SOLUTIONS 

The  design  problems  encountered  after  the  detector  basic  concept  was  proven  involved  meeting  the  operational  life  requirements  of  the  or- 
biter.  The  problems  and  their  solutions  are  as  follows. 


Quartz  Crystal  Microbalance  (QCM)  Sensor 

The  original  design  used  a QCM  as  the  sensing  device  to  measure  the  rate  of  mass  change  that  was  collected  on  the  crystal,  which  was  the 
signal  generator  of  an  alarm.  The  problem  with  this  system  was  in  providing  adequate  crystal  life  to  meet  the  design  goal.  Even  in  a clean  environ- 
ment, constant  particle  collection  was  enough  to  saturate  the  crystal  within  a relatively  short  time.  Attempts  to  regenerate  the  crystal  remotely  were 
cumbersome  and  required  considerable  development.  At  this  time,  the  use  of  an  ionization  chamber  as  a substitute  for  the  QCM  was  introduced. 
This  chamber’s  life  was  a function  of  the  radioactive  source’s  longevity  (half  life  equals  458  years).  This  substitution  did  not  jeopardize  the  pro- 
gram objectives  and  solved  the  sensor  life  problem. 


Ionization  Chamber  Altitude  Operation 

The  ionization  characteristics  of  a low-energy  alpha  source  vary  with  the  density  of  the  surrounding  air.  In  order  to  provide  signal  compensa- 
tion for  minor  changes  in  the  ambient  atmosphere,  this  detector  contains  two  low-energy  sources  in  its  sensing  and  reference  chambers,  as  seen  in 
Figure  4.  The  orbiter  altitude  pressure  requirement  for  this  system  is  8 psia  (16,000  feet)  and  is  tested  to  7.3  psia  to  provide  margin.  During  altitude 
testing  of  the  sensors,  a large  signal  shift  in  some  units  and  no  shift  in  others  (up  to  50,000  feet)  was  observed.  It  was  concluded  that  there  had  to  be 
differences  in  the  two  ionization  sources  to  create  the  unbalance  in  the  electrical  current  that  was  generated  between  the  two  chambers.  The  two 
parameters  controlling  the  source  characteristics  are  energy  level  (mean  electron  volts  [MEV])  and  activity  (microcuries).  If  these  characteristics 
are  matched,  the  sensor  signal  will  remain  balanced;  however,  this  is  not  easy  to  accomplish. 


A series  of  matrix-oriented  tests  were  conducted  to  pinpoint  the  characteristic  that  most  affected  the  signal  shift.  The  most  effective  results 
were  first  obtained  by  maintaining  one  source  as  a constant  and  varying  the  second.  Through  extensive  analysis  and  testing,  the  upper  and  lower 
limit  values  that  produced  the  desired  results  were  determined  for  both  activity  and  energy  levels.  These  values  were  then  used  to  pair  the  sources 
before  being  installed  in  the  sensor.  This  selection  process  doubled  the  number  of  acceptable  sensors;  however,  manufacturing  assembly  techni- 
ques still  create  source  characteristic  changes  that  prevent  100  percent  of  acceptable  units  even  after  selection. 


The  importance  of  this  solution  is  that  it  determined  how  to  minimize  the  sensor  signal  from  shifting  during  changes  in  ambient  air  density. 
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Air  Moving  Pump  Design 


Two  problems  were  encountered  during  the  development  of  the  rotary  vane  air  moving  pump:  one  involved  the  material  used  to  make  the 
vanes  and  the  second  involved  contact  friction  between  the  rotor  and  the  mating  end  surface  during  vibration  testing.  This  design  is  shown  in 
Figure  5. 

The  original  vanes  were  made  from  a graphite-impregnated  resin  material  that,  by  design,  deposits  a thin  layer  of  resin  on  the  housing  wall  to 
improve  pump  efficiency.  Unfortunately,  this  deposit  also  increases  the  friction  forces  because  the  graphite  does  not  form  a perfect  lube  surface 
and,  therefore,  the  motor  torque  requirements  are  higher.  To  overcome  this  would  have  meant  increasing  the  motor  power  to  an  undesirable 
value.  Various  materials  were  tested  that  showed  high-pressure  velocity  (PV)  characteristics,  but  only  one  passed  the  design  criteria.  That  material 
is  a cadmium  oxide  impregnated  Teflon  called  Fluoroloy  D and  it  has  successfully  operated  in  excess  of  12,000  hours  without  appreciable  wear. 

The  contact  friction  problem  during  vibration  testing  was  solved  by  designing  the  small  diameter  rotor  retainer  such  that  it  always  protrudes 
above  the  rotor  face.  This  means  that  only  it  can  contact  the  mating  surface,  thus  preventing  contact  with  the  entire  diameter  of  the  rotor  face. 
Also,  the  retainer  was  made  of  heat-treated  17-7  Ph  and  the  mating  surface  was  finished  with  a Class  I anodize  so  that  any  contact  between  them 
involved  two  very  hard  surfaces. 


Pump  Driving  Motor  Design 

The  major  problem  in  the  design  of  the  pump  motor  was  the  selection  of  dry  lube  bearings  in  order  to  minimize  the  power  consumption.  This 
type  of  bearing  did  not  provide  the  expected  motor  life.  A design  change  to  wet  lube  bearings  required  an  increase  in  power  to  overcome  the  higher 
friction  load;  however,  it  was  possible  to  reduce  the  motor  speed  to  increase  its  driving  torque  without  exceeding  the  allowable  power  consumption. 
This  change  resulted  in  a 20, 000-hour  operational  life  motor. 

Because  of  the  lower  motor  speed,  the  lower  pump  flow  had  to  be  compensated  for  in  order  to  maintain  the  same  sensor  performance.  This 
was  accomplished  by  a size  change  to  the  orifice  that  controls  the  flow  split  through  the  sensor. 

Electronics  Hybrid  Design 

When  the  previously  discussed  motor  speed  change  was  made,  the  motor  controller  hybrid,  which  supplies  the  correct  driving  frequency  to 
the  motor,  required  a new  design.  It  was  a straightforward  change  to  provide  the  new  frequency. 

Another  function  of  this  hybrid  is  to  supply  the  self-test  signal  that  verifies  the  running  condition  of  the  motor.  The  original  design  measured 
the  running  current  to  determine  either  a stalled  or  open-winding  condition.  The  current  window  available  to  make  this  determination  was  very 
narrow  because  of  the  hysteresis  effect  on  the  current,  and,  consequently,  a false  not-running  condition  would  occasionally  be  indicated.  A new 
self-test  circuit  design  was  introduced  to  eliminate  this  problem. 

The  new  self-test  circuit  examines  the  motor  current  wave-form  frequency  instead  of  current  level  to  determine  an  open  winding,  thereby 
making  this  function  independent  of  normal  running  current  changes.  Since  this  eliminates  the  aforementioned  current  window,  it  allows  setting 
the  stall  point  indicator  very  close  to  the  actual  stall  value,  which  maximizes  the  most  self-test  life. 


VANE 


FIGURE  5.  PUMP/MOTOR  ASSEMBL  Y 
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REMOVAL  OF  HYDROGEN  FROM  FUEL  CELL  PRODUCT  WATER  USING 
LOW  TEMPERATURE  CATALYZED  METAL  TUBES 


The  water  management  system  (WMS)  of  the  Shuttle  orbiter  relies  upon  the  water  produced  by  its  fuel  cells  to  replenish  that  water  used  for 
either  metabolic  consumption  by  the  crew  or  in  the  Shuttle’s  flash  evaporator.  However,  the  water  produced  by  the  fuel  cells  is  saturated  with 
hydrogen  (H2)  at  the  operating  conditions  of  the  fuel  cell  (150°F,  60  psia),  which  results  in  0.066  cubic  centimeter  of  hydrogen  being  dissolved  in 
every  cubic  centimeter  of  water  produced.  In  the  process  of  water  storage  and  consumption,  hydrostatic  pressure  is  decreased,  which  causes  the 
dissolved  hydrogen  to  come  out  of  solution  and  revert  to  the  gaseous  phase  unless  provisions  are  made  to  remove  a major  portion  of  it  from  the 
water.  The  technique  that  has  been  selected  for  removal  of  hydrogen  from  the  fuel  cell  generated  water  is  based  upon  the  use  of  catalyzed 
palladium/silver  (Pd/Ag)  tubes  operating  at  ambient  temperature.  Fuel  cell  product  water  flows  on  the  inside  of  the  tubes  while  space  vacuum  is 
applied  to  the  outside  tube  surfaces  causing  the  hydrogen  to  pass  through  the  solid  metal  tubes  to  space  vacuum.  This  hydrogen  removal  concept 
was  first  qualified  aboard  Apollo  spacecrafts;  however,  to  satisfy  the  removal  requirements  for  the  Shuttle  orbiter  the  hydrogen  separator  was  re- 
quired to  demonstrate  an  absolute  hydrogen  removal  capacity  of  approximately  ten  times  that  of  units  built  for  the  Apollo  spacecraft.  In  addition, 
reductions  in  relative  weight  and  volume  were  required. 

The  challenges  of  developing  such  a lightweight,  high  performance  hydrogen  separator  for  the  Shuttle  orbiter  were  successfully  met,  but  not 
without  development  hurdles  and  problems  that  required  timely  and  creative  solutions.  The  following  discusses  the  major  development  challenges 
and  problems  encountered  and  how  their  solutions  were  implemented. 


PROBLEMS  AND  CHALLENGES 

The  major  challenge  of  the  hydrogen  separator  development  can  be  summarized  in  one  statement:  reduce  size  by  a factor  of  three  (compared 
to  Apollo  hardware)  and  increase  capacity  by  a factor  of  ten. 

Specifically,  the  requirements  that  had  to  be  met  were  a hydrogen  removal  rate  equal  to  or  greater  than  70  percent  with  product  water  flowing 
at  23  pounds  per  hour  at  ambient  temperature  (70°F  ± 2),  without  inducing  a pressure  drop  of  greater  than  0.7  psid.  Maximum  allowable  hydrogen 
separator  weight  was  5 pounds. 


PROBLEM  RESOLUTIONS 
Performance  Enhancement 

Calculations  and  experimental  data  indicated  that  to  remove  a minimum  of  70  percent  of  the  dissolved  and/or  free  hydrogen  from  water 
flowing  at  a rate  of  23  pounds  per  hour  and  at  ambient  conditions  would  require  a total  water  flow  path  length  in  excess  of  900  inches.  The 
calculations  were  based  on  catalyzed  Pd/Ag  tubes  optimized  at  a 0.125-inch  diameter  and  a wall  thickness  of  0.010  inch.  Since  a single  900-inch 
path  length  would  exceed  the  allowable  APof  0.7  psid  and  internal  catalyzation  of  the  tube  would  be  impractical,  a technique  for  manifolding  the 
hydrogen-saturated  water  flow  into  a combination  of  shorter  series/parallel  lengths  was  devised.  This  manifold  technique  permitted  the  use  of 
16  Pd/Ag  tubes,  with  each  tube  having  a path  length  of  57  inches.  This  series/parallel  configuration  permitted  the  fuel  cell  product  water  to  enter 
eight  inlet  tubes  simultaneously  (Figure  6)  and  flow  through  these  tubes  in  parallel;  exit  from  the  initial  eight  tubes  and  simultaneously  enter  into  a 
set  of  four  parallel  outlet  tubes  manifolded  in  series  with  the  initial  eight  inlet  tubes.  The  water  then  exited  the  first  four  outlet  tubes  and 
simultaneously  entered  a second  set  of  four  parallel  outlet  tubes  manifolded  in  series  with  the  first  set  of  four  outlet  tubes.  The  product  water 
passing  through  the  second  set  of  four  tubes  then  exited  into  a common  water  outlet  port.  This  series  parallel  manifolding  technique  divided  the 
tubing  into  catalyzable  lengths,  met  the  required  pressure  drop,  and  still  maintained  sufficient  residence  time  within  the  catalytic  Pd/Ag  tubes  to 
meet  the  hydrogen  removal  requirements. 

While  the  calculations  predicted  satisfactory  performance,  initial  verification  testing  with  the  development  unit  showed  less  than  the 
calculated  70  percent  removal  efficiency.  Through  a series  of  bench  top  experiments,  the  reduced  removal  rate  was  traced  to  the  final  10  percent 
through  15  percent  length  of  each  flow  path,  i.e.,  where  only  dissolved  (as  opposed  to  free)  hydrogen  exists  with  the  water.  Since  flow  is  laminar  in 
these  regions,  dissolved  hydrogen  near  the  center  of  the  tubes  reaches  the  walls  only  by  diffusion. 


The  solution  to  enhancing  the  removal  rate  in  the  diffusion-only  regions  consisted  of  developing  small  turbulators  inserted  into  the  last 
10  inches  of  each  tube  path  of  the  first  set  of  four  outlet  tubes  and  into  the  first  and  last  10  inches  of  each  tube  path  of  the  second  set  of  four  outlet 
tubes  (12  turbulators).  These  thin,  spiral-like  metal  turbulators  were  designed  to  break  up  or  turbulate  the  laminar  flow  characteristics  of  the 
water.  This  allowed  hydrogen  trapped  at  the  center  of  the  water  column  to  reach  the  catalyzed  tube  surfaces  and  thereby  enhance  its  removal. 


PACKAGING 

The  use  of  16  separate  tubes  proved  feasible  from  a performance  standpoint.  The  need  for  creative  solutions  to  the  inherent  challenge  of 
packaging  16  tubes,  each  57  inches  long,  into  a package  weighing  5 pounds  or  less  remained  to  be  solved.  First,  a technique  had  to  be  devised  for 
bending  the  tubes  into  a double-U  configuration  with  each  tube  having  three  180-degree  bends.  To  achieve  a compact  configuration,  an  extremely 
small  bend  radius  was  desired,  smaller  than  standard  (0.50  inch)  bend  radii  normally  associated  with  0.125  inch  diameter  tubing.  Since  the  Pd/Ag 
tubes  were  of  such  a small  diameter  and  thin-wall  construction,  bending  the  tubes  in  a very  tight  radius  by  using  conventional  techniques  resulted 
in  crimping  or  collapsing  the  tube.  To  resolve  this,  the  Pd/Ag  tube  (in  its  initial  60  inches  of  straight  length)  was  sealed  at  one  end  (crimped  shut) 
and  carefully  filled  with  a nonabrasive,  nontoxic  water-soluble  packing.  Once  the  tube  was  filled,  the  open  end  of  the  tube  was  crimped  shut. 
Bending  of  the  tubes  to  a 0.31 -inch  radius  was  then  successful  and  reproducible.  Once  the  tubes  were  bent,  the  crimped  ends  were  cut  off  and  water 
was  flushed  through  the  tubes  to  remove  the  water  soluble  packing. 
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FIGURE  6.  HEAD  PLA  TE  SHOWING  Pd/Ag  TUBE  LOCA  TIONS  AND  MANIFOLD  SEAL  CONFIGURA  TION 


Locating  the  tubes  into  a common  header  plate  posed  the  problem  of  performing  32  separate  welds  (one  weld  for  each  end  of  the  16  Pd/Ag 
tubes)  in  a nickel  plate  designed  to  be  3.5  inches  in  diameter  and  0.1 10-inch  thick.  Heli-arc  welding  techniques  were  examined  and  rejected  since 
the  heat  generated  could  warp  the  thin  header  plate  and  the  potential  for  welding  error  and  subsequent  increased  scrap  rates  was  high.  Electron 
beam  (EB)  welding  was  selected  as  a viable  technique  to  secure  the  tubes  into  the  header  plate.  A treepan-type  weld  (Figure  7)  was  initially  con- 
sidered but  was  rejected  when  calculations  showed  that  stress  on  the  weldment  of  the  treepan-configured  joint  was  too  severe.  Additionally, 
reproducibility  of  an  EB  weld  using  a treepan  joint  was  suspect.  An  EB  weld  technique  using  a butt-weld  configuration  between  the  Pd/Ag  tubes 
and  the  header  plate  (Figure  8)  was  developed  and  qualified  for  weld  integrity,  structural  strength,  and  reproducibility. 


In  order  for  the  tube  bundle  of  the  welded  Pd/Ag  tube  and  header  assembly  to  withstand  the  shock  and  vibration  conditions  experienced 
aboard  the  Shuttle  orbiter,  a technique  for  forming  a tube  bundle  was  devised.  The  technique  allowed  for  tube  growth  (about  0.375  inch  for  the 
16-inch  lengths)  characteristic  of  Pd/Ag  metal  exposed  to  hydrogen.  A porous  Teflon  cord  was  selected  for  the  tube  tie-down  and  support 
technique.  The  Teflon  cord  was  laced  through  the  tubes  in  a braiding  fashion,  with  the  ends  of  the  Teflon  cord  tied  together  to  form  a secure  lace 
through  the  tube  bundle.  This  Teflon  cord  braiding  at  various  locations  on  the  tube  bundle  secured  the  tubes  of  the  bundle  to  resist  the  effects  of 
shock  and  vibration  and  at  the  same  time  minimize  cover  up  of  the  catalyzed  outside  surface  of  the  Pd/Ag  tubes,  which  could  result  in  reduced 
separator  performance  and  allow  adequate  tube  growth. 


Photographs  of  an  assembled  hydrogen  separator  and  its  components  are  presented  in  Figures  9 and  10,  respectively.  Key  features  and  com- 
ponents are  identified. 
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FIGURE  7.  CROSS  SECTION  OF  A TREEPAN  WELD 
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WATER  INLET 


FIGURE  9.  ASSEMBLED  H2  SEPARATOR 
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ASSEMBLY 


FIGURE  10.  H2  SEPARA  TOR  COMPONENTS 
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FLIGHT  EXPERIENCE 


Shortly  after  STS-2  was  launched,  a high  PH  alarm  occurred,  which  indicated  potassium  hydroxide  (KOH)  in  the  fuel  cell  produced  water. 
The  supply  water  system  was  configured  to  isolate  the  contaminated  water  from  the  drinking  supply.  The  problem  fuel  cell  was  shut  down  and  the 
mission  was  successfully  completed.  After  this  problem,  the  crew  reported  gas  in  the  drinking  water.  It  was  suspected  that  the  KOH  had  poisoned 
the  separator  catalyst.  The  following  actions  were  undertaken: 

• Hydrogen  separator  performance  was  tested  at  Life  Systems,  Inc. 

• Water  dispenser  servicing  techniques  were  reviewed. 

• Drink  bags  were  tested  for  residual  gas. 

Tests  on  the  separator  showed  that  the  KOH  had  not  affected  its  performance;  however,  servicing  procedures  used  for  the  water  dispenser 
could  have  trapped  air  in  it,  which  was  later  displaced  during  the  mission.  Also,  the  water  drink  bags,  which  were  serviced  by  evacuation  were 
determined  to  be  slightly  permeable  to  air.  It  was  concluded  that  the  last  two  conditions  were  the  cause  of  the  problem. 


To  minimize  recurrance  on  future  flights,  water  dispenser  procedures  have  been  changed  to  preclude  air  entrapment.  Water  bags  are 
evacuated  as  late  as  possible  to  minimize  air  permeation.  No  change  was  necessary  for  the  separator. 

CONCLUSIONS 

Solution  to  key  challenges  in  performance  and  packaging  resulted  in  the  successful  development  of  a hydrogen  separator  that  was  capable  of 
removing  greater  than  70  percent  of  the  dissolved  hydrogen  from  the  fuel  cell  product  water  at  ambient  temperatures  and  at  a flow  rate  of 
23  pounds  per  hour  within  the  specified  pressure  drop  of  0.7  psid.  The  compact  unit  had  a total  length  of  16.8  inches,  an  outside  diameter  of 
3.5  inches,  and  not  only  met  the  5-pound  weight  goal  but  beat  it  by  34  percent,  weighing  only  3.3  pounds. 


WASTE  COLLECTOR  SYSTEM  (WCS) 

The  major  achievement  of  the  WCS  was  to  focus  the  problems  of  waste  management  into  one  integrated  multifunction  assembly  (Figure  1 1). 
The  WCS  collects  and  processes  human  wastes,  wash  and  extravehicular  mobility  unit  (EMU)  dump  water,  and  trash  vent  gases  in  a sanitary  and 
odor-free  manner.  Specific  challenges  were  to  simplify  user  procedures  while  minimizing  weight,  power,  and  volume  requirements.  There  were 
significant  achievements  in  several  areas,  including: 

• Zero  gravity  operation 

• Valve  design 

• Liquid/gas  separation 

• Corrosion  protection 


ZERO  GRAVITY  OPERATION 

Simplified  operational  mechanisms  and  procedures  for  crew  accommodation  and  restraint  systems  were  developed  through  the  use  of  past 
history,  neutral  buoyancy  tests,  and  aircraft  tests  of  many  concepts.  Final  proof  was  obtained  during  STS  flights  where  sufficient  zero  gravity  time 
was  available  for  full  evaluation. 


RESTRAINT  SYSTEM 

Prior  to  STS-5,  the  WCS  restraints  relied  on  a seat  belt  and  a fixed-foot  support.  STS-1  through  STS-4  data  indicated  that  these  methods 
were  inadequate  for  reliable  user  positioning  and  restraint.  A number  of  options  were  evaluated  on  STS-5  and  several  became  operational. 

Spring-loaded  thigh  bar  restraints  are  self-stowing,  easily  positioned  for  use,  permit  a no-hands  required  retention  of  the  user,  and  offer  the 
user  additional  handholds  for  zero-gravity  locomotion  in  the  stowed  position.  No  actions  are  necessary  for  stowage  for  launch  and  entry. 

Foot  restraints,  consisting  of  a heel  cup  and  toe  straps,  were  added  to  an  adjustable  foot  support  for  additional  user  restraint  and  height 
adjustment,  if  desired. 

A user-adjustable  toe  bar  was  also  added  to  provide  a restraint  means  for  standing  maturations  in  the  zero-gravity  environment.  The  toe  bar 
is  used  with  the  footrest  in  the  stowed  position.  Restraint  systems  are  shown  in  Figure  12. 

URINAL  CAPS 

Prior  to  STS-5,  a common  urinal  cap  was  utilized  for  both  males  and  females.  The  STS-4  crew  reported  urine  migration  under  the  cap  in  the 
unsealed  area  between  the  urinal  and  the  cap.  This  open  area  had  been  provided  for  proper  air  flow  when  the  cap  was  used  by  a female.  In  addi- 
tion, the  crew  also  reported  the  last-drop  problem. 
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FIGURE  11.  WCS  ASSEMBL  Y FIGURE  12.  THIGH  BAR  AND  FOOT  SUPPORT 

WITH  HEEL  CUP,  TOE  STRAPS,  AND  TOE  BAR 


Several  revisions  were  made  to  the  caps  for  a male-only  design.  The  mating  area  between  the  urinal  and  the  cap  was  sealed  by  addition  of  a 
rubber  gasket.  This  directed  all  air  through  the  top  opening  only,  which  increased  the  effective  air  velocity  and  eliminated  a leakage  path. 

There  were  several  options  for  the  cap  opening  to  support  in-orbit  testing.  The  cap  variations  included  the  large  rectangular  opening  (the 
common  male-female  cap  with  rubber  gasket  added),  a centered  hole  opening,  and  an  off-set  hole  opening,  as  shown  in  Figure  13.  The  smaller 
opening  area  of  the  latter  two  versions  increased  the  air  velocity  at  the  collection  point  to  aid  in  last-drop  removal. 


TYPICAL  SECTION 


DEBRIS 

COVER 


FIGURE  13.  URINAL  CAPS 
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In-flight  testing  of  these  three  male-only  caps  was  limited  to  the  off-set  hole  version  by  the  STS-5  crew,  as  it  was  very  effective.  No  reports  of 
liquid  migration  were  received  with  the  new  cap.  In  addition,  when  combined  with  the  pinch  valve  urinal,  collection  of  the  last  drop  ceased  to  be  a 
problem. 

In  order  to  limit  debris  accumulation  in  the  urinal,  a cap  with  a debris  screen  was  provided  to  cover  the  urinal  when  not  in  use.  This  was 
effective  in  preventing  ingestion  of  cabin  debris. 


URINAL  DEBRIS  PROBLEM 

STS-1  revealed  problems  related  to  unexpected  amounts  of  cabin  debris.  During  operation  of  the  WCS,  cabin  air  (8  scfm)  is  drawn  into  the 
urinal  for  liquid  transport.  After  the  STS-1  flight,  when  tested  in  a dry  condition,  the  urinal  screen  was  found  to  be  nearly  blocked  with  lint  and 
debris.  When  wetted  with  liquid  in  zero  gravity,  the  urinal  air  flow  was  further  impaired  such  that  the  clogged  screen  acted  as  a liquid/gas 
separator. 

Because  of  the  suction  of  the  fan-separator,  the  liquid  thus  tended  to  collect  downstream  of  the  screen  in  large  liquid  slugs  with  small  pockets 
of  air.  This  is  compared  to  normal  operation  where  only  small  slugs  of  liquid  are  separated  by  relatively  large  pockets  of  air.  The  result  was  an  ex- 
cessive instantaneous  urine  flow  to  the  fan  separator,  which  overwhelmed  the  centrifugal  phase  separator  and  carried  over  to  the  fan,  which  forced 
the  urine  with  the  air  to  the  odor  filter. 

The  problem  was  solved  by  adding  a single  filter,  called  a prefilter,  to  the  urinal,  as  shown  in  Figure  14.  The  prefilter  is  easily  changed  on  a 
daily  basis  to  prevent  debris  buildup.  Subsequently,  the  WCS  operated  successfully  to  confirm  the  postulated  cause  of  the  problem.  Because  of  ex- 
cessive debris  collection  in  the  urinal,  the  urinal  prefilter  will  continue  to  require  periodic  replacement  in  flight. 


VALVE  DESIGN 

Manual  operation  of  control  valves  was  dictated  by  the  weight  and  power  limitations  and  the  complexity  of  the  interlocking  and  sequencing 
of  functions.  As  a consequence,  the  valves  typically  required  low  operating  forces  for  the  required  large  orifices.  The  large  4-inch  sliding  gate  valve 
that  opens  the  commode  for  defecation  is  also  a vacuum  seal.  The  pressure  differential  on  the  gate  is  relieved  prior  to  opening  to  minimize 
operating  force  and  structural  weight. 

Conversely,  the  pressure  differential  on  the  floating  gate  is  used  to  achieve  sealing  pressure  against  a simple  O ring  when  the  commode  is 
closed  for  vacuum  drying  of  the  solid  wastes. 

Similarly,  a three-way  1-1/2  inch  ball  valve  used  for  air  flow  control  and  vacuum  sealing  utilizes  a floating  seal  design  to  achieve  sufficient 
pressure  for  sealing  while  operating  at  a low  torque  of  less  than  25  inch-pounds. 

A third  unique  valve  design  developed  for  the  WCS  was  a simple  pinch  valve  for  air  flow  control  in  the  urinal,  as  shown  in  Figure  14.  An  air 
flow  of  8 scfm  is  used  to  entrap  the  urine  and  convey  it  through  a funnel  to  a liquid/gas  separator.  The  last  drop  of  urination  is  often  as  large  as  a 
tablespoon  of  liquid,  which  has  always  been  a disposal  problem  in  zero  gravity.  For  the  WCS,  this  is  collected  by  diverting  the  suction  air  flow  to  a 
port  at  the  top  of  the  collection  funnel,  which  is  achieved  by  squeezing  a rubber  tube  at  the  base  of  the  funnel,  stopping  the  main  flow  air,  and 
causing  a small  amount  of  suction  flow  at  the  top  port.  The  user  merely  touches  the  drop  to  the  port  and  the  liquid  is  drawn  into  the  system. 


PREFILTER 


FIGURE  14.  URINAL/PINCH  VAL  VE  ASSEMBL  Y 
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LIQUID/GAS  SEPARATION 


Separation  of  urine  and  other  waste  liquids  from  the  transport  air  presented  a number  of  design  challenges.  Foremost  was  the  need  to  achieve 
reliable  phase  separation  at  minimal  weight  and  power  consumption.  One  method  used  to  accomplish  this  goal  was  the  integration  of  three  func- 
tions into  the  fan  separator  (Figure  15):  liquid/gas  phase  separation,  liquid  pumping,  and  air  flow  pressurization.  Power  requirements  were  fur- 
ther reduced  by  eliminating  high  friction  dynamic  seals  and  maintaining  proper  pressure  differentials  at  required  seal  locations.  By  properly 
designing  the  flow  paths  for  the  commode  and  urinal  air  flows,  it  was  possible  to  maintain  a lower  internal  pressure  in  the  rotating  bowl  than  that 
between  the  bowl  and  the  external  housing.  This  condition  prevents  any  liquid  leakage  out  of  the  bowl  and  eliminates  the  need  of  a seal,  which 
would  add  a significant  cost  in  power,  complexity,  and  reliability. 

When  the  liquid/air  mixture  reaches  the  fan  separator,  the  liquid  is  centrifugally  separated  from  the  air  and  pumped  out  of  the  unit  through 
a stationary  pitot  tube  in  the  separator.  The  fan  separator  is  designed  to  produce  sufficient  air  flow  for  the  operation  of  the  urinal  and  the 
commode.  Since  the  commode  is  not  necessarily  used  during  micturition,  a ballast  air  flow  of  approximately  30  cfm  enters  the  system  via  a par- 
ticulate filter,  a calibrated  orifice,  and  valve.  The  air  mixes  with  the  urine  transport  air  flow  in  the  fan  separator  to  assure  that  moisture  in  the 
warm  urine  transport  air  does  not  condense  in  the  cooler  outlet  line. 


CREW  TRAINING 

Crew  comments  during  flight  debriefing  indicated  that  considerable  difficulties  were  being  experienced  in  obtaining  the  proper  position.  As  a 
result,  a special  training  aid  was  designed,  utilizing  a television  camera  to  assist  the  crew  in  obtaining  proper  positioning.  In  addition,  the  WCS 
development  was  utilized  during  flight  simulations  by  the  flight  crew.  Comments  from  crew  personnel  who  have  utilized  the  training  aid  indicate 
that  it  is  very  effective. 


CONCLUSIONS 

The  greatest  challenge  in  developing  the  WCS  was  integrating  multiple  waste  management  functions  into  a single  flight  assembly.  In  addition 
to  the  typical  flight  constraints  of  minimal  power,  weight,  and  volume,  other  requirements  imposed  on  the  WCS  included  ease  of  operation,  user 
acceptance,  liquid/gas  separation  performance,  and  satisfactory  materials  protection  against  the  various  waste  products. 

Flight  experience  has  confirmed  the  basic  design  integrity  of  the  WCS  and  that  the  principles  of  operation  in  zero  gravity  were  correct. 
Modifications  that  have  been  incorporated  have  improved  positioning  and  restraint  methods  utilizing  user-accepted  systems. 


BLOWER 
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ABSTRACT 


SYSTEM  DESCRIPTION 


This  paper  describes  major  technical 

challenges  which  were  met  in  the  design  and 
development  of  the  Space  Shuttle  Orbiter 

Radiator  System.  This  system  rejects  up  to  30 
kW  of  waste  heat  from  eight  individual  radiators 
having  a combined  surface  area  of  175m2.  The 
radiators,  which  are  deployable,  are  mounted  on 
the  inside  of  the  payload  bay  doors  for 

protection  from  aerodynamic  heating  during 
ascent  and  re-entry.  While  in  orbit  the  payload 
bay  doors  are  opened  to  expose  the  radiators  for 
operation.  An  R21  coolant  loop  accumulates 
waste  heat  from  various  components  in  the 

Orbiter  and  delivers  the  heat  to  the  radiators 
for  rejection  to  space.  Specific  challenges 
included  high  acoustically  induced  loads  during 
lift-off,  severe  radiating  area  constraints, 
demanding  heat  load  control  requirements,  and 
long  life  goals.  Details  of  major  design  and 
analysis  efforts  are  discussed.  The  success  of 
the  developed  hardware  in  satisfying  mission 
objectives  showed  how  well  the  design  challenge 
was  met. 


INTRODUCTION 

The  Space  Shuttle  Orbiter  offered  a 
significant  challenge  to  radiator  designers 
since  the  high  reentry  heat  flux  preludes  the 
use  of  conventional  externally  mounted 
radiators.  Mounting  the  radiators  on  the  inside 
of  the  payload  bay  doors  provided  a solution  to 
this  problem.  The  doors  provide  reentry  thermal 
protection  to  the  radiators,  and  there  is  no 
disadvantage  associated  with  having  the  doors 
open  while  the  radiators  are  In  operation.  This 
placement  solved  a difficult  problem,  but  it 
created  several  challenges  in  radiator  design 
which  are  discussed  in  this  paper.  These 
challenges  are  primarily  related  to  the 
radiating  area  and  attachment  limitations 
inherent  in  the  payload  bay  door  mounting 
scheme,  the  launch  vibration  environment,  the 
wide  operating  temperature  range  (-130°C  to 
120°C)  and  stringent  heat  transfer  and  coolant 
pressure  drop  constraints.  A systems 

engineering  approach  was  applied  universally  to 
design  parameters  because  of  the  unusually  close 
(for  a radiator  system)  interrelationship  of  the 
parameters.  The  final  radiator  design  will  be 
discussed  briefly,  and  then  some  of  the  major 
challenges  associated  with  the  Shuttle  Orbiter 
radiator  design  will  be  addressed. 


The  Orbiter  radiator  system  is  described 
in  detail  in  Reference  [1]  and  flight 
performance  is  described  in  Reference  [2], 
Briefly  the  radiator  system  consists  of  eight 
radiators  which  are  evenly  divided  between  two 
independent  Refrigerant  21  (Freon  21)  flow 
loops.  Figure  1 shows  the  routing  of  one  R21 


loop  through  the  four  radiators  mounted  on  one 
side  of  the  payload  bay  door.  Radiator  outlet 
temperature  control  is  achieved  by  simply 
bypassing  hot  R21  around  the  radiators  in  the 
proper  quantity  such  that  the  mixed  temperature 
of  the  hot  bypassed  flow  and  the  cold  flow  from 
the  radiator  is  at  the  desired  control  point,  as 
shown  in  Figure  2. 


Figure  2 Radiator  Temperature  Control  Approach 
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The  eight  radiators  are  curved  to  conform 
to  the  payload  bay  doors.  Each  radiator  is 
about  3.2  m along  the  curved  section  by  4.6  m in 
the  longitudinal  axis,  as  shown  in  Figure  3. 


Figure  3 Typical  Radiator  Panel  Physical  Characteristics 


The  forward  two  radiators,  which  may  be  deployed 
from  the  door  to  increase  radiator  area  are  each 
about  2.3  cm  thick,  while  the  aft  two  radiators 
on  each  side  are  about  1.3  cm  thick.  The 
radiators  are  made  of  bonded  aluminum  honeycomb 
structure  with  tubes  attached  to  the  facesheets 
as  shown  in  Figure  4. 


HEAT  REJECTION  OPTIMIZATION 

The  limited  heat  transfer  area  of  the 
inside  of  the  payload  bay  doors,  which 

represents  about  118  sq.m.,  proved  to  be 
inadequate  for  the  required  heat  rejection  of 
about  20  kWt  in  the  popular  flight  attitude  of 
payload  bay  toward  the  earth.  This  made  it 

necessary  to  deploy  the  forward  radiators  away 
from  the  doors,  as  shown  in  Figure  1,  creating  a 
cavity  into  which  additional  heat  is  radiated 
from  the  underside  of  the  radiators.  Evaluating 
heat  transfer  performance  gain  provided  by  the 
cavity  was  difficult  due  to  the  specular 
silver-backed  Teflon  surface  coating  on  the 


inside  of  the  door  and  radiators.  The 
radiators  had  to  be  optimized  for  maximum  heat 
radiating  efficiency  rather  than  minimum  weight 
and  an  effective  means  of  applying  a long 
lasting  optical  solar  reflection  coating  to  the 
radiator  had  to  be  devised.  These  challenges 
are  discussed  in  the  succeeding  subsections. 

PAYLOAD  BAY  DOOR-RADIATOR  CAVITY  ANALYSIS 

In  order  to  accurately  predict  the  heat 
rejection  rates  from  the  door-radiator  cavity  by 
thermal  radiation,  radiative  exchange  factors 
from  surface-to-surface,  from  surface-to-space , 
and  from  sun-to-surf ace  must  be  determined.  The 
calculation  of  radiant  interchange  is  commonly 
performed  under  the  assumption  that  the 
participating  surfaces  are  diffuse  emitters  and 
diffuse  reflectors  of  radiant  energy. 
Experimental  investigations,  however,  have  shown 
that  real  surfaces  can  depart  substantially  from 
this  model,  particularly  in  the  case  of  smooth 
and/or  metallic  surfaces.  Extreme  examples  are 
deep  cavities  exposed  to  incoming  radiation 
(e.g.,  solar)  or  outgoing  radiation  (e.g.,  heat 
rejection  into  space),  as  are  encountered  in  the 
Space  Shuttle  payload  bay  door-radiator 
configuration. 

Two  different  methods  of  calculating 
radiation  exchange  factors  in  complex  geometries 
with  complex  surface  characteristics  are 
possible:  the  statistical  approach  (usually 

called  the  Monte  Carlo  method),  and  the  analytic 
approach,  solving  a set  of  simultaneous  integral 
equations  numerically.  The  different  approaches 
require  different  definitions  for  the 

radiative  exchange  factors.  Any  numerical 
method  including  three-dimensional  effects  will 
be  complex  and  computer  time-consuming,  even  if 
idealized  surface  properties  are  assumed. 
Extremely  complex  cases  such  as  the  payload  bay 
door-radiator  cavity  with  its  curved  surfaces 
and  its  non-ideal  surface  characteristics  are  an 
ideal  application  for  the  Monte  Carlo  technique, 
which  was  employed  here. 

Heat  Transfer  Relations 


Assuming  that  the  door-radiator  cavity 
can  be  broken  up  into  J isothermal  subsurfaces 
(strips)  as  shown  in  Fig.  5,  the  net  heat  flux 
for  any  strip  i may  be  calculated  from 
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external  energy  entering  through 
the  opening  of  the  enclosure, 
area  of  the  opening  irradiated  from 
external  sources , 
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strip  temperature, 

total  hemispherical  emissivity  of 
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Although  heat  fluxes  can  be  calculated 

directly  by  the  Monte  Carlo  method,  it  is  of 
advantage  to  instead  determine  the  exchange 
factors:  although  the  Qi*s  depend  on  all 
surface  temperatures  in  the  enclosure,  the 
*/-/' s either  do  not  (gray  surfaces)  or  depend 
only  on  the  temperature  of  the  emitting  surface 
(nongray  surfaces). 

If  a large  statistical  sample  of  energy 
bundles  is  emitted  from  surface  A^,  and 

if  the  N^j  becomes  absorbed  by  surface  Aj 

after  direct  travel  or  after  any  number  of 

reflections,  then  the  exchange  factor  may  be 

calculated  from 


Surface  Properties. 

The  accurate  calculation  of  radiation 
exchange  factors  requires  an  extensive  knowledge 
of  surface  property  data.  In  general,  the 
spectral  directional  emissivity  and  absorptivity 
as  well  as  the  bidirectional  reflectively  must 
be  known  for  the  material  for  all  wavelengths, 
directions  (incoming  and/or  outgoing  solid 
angles  cu),  and- temperatures;  i.e., 

Qt\  = f \ = /(X,  (*)%  T)  P\  * /(X,  W|n»  T)  [ ^ ] 

These  surface  properties  must  be 
determined  from  experiment  and/or 

electromagnetic  wave  theory.  No  complete  set  of 
surface  property  data  was  avilable  for 
silver-backed  Teflon,  in  particular  as  far  as 
bidirectional  reflectivity  Pa  is  concerned. 

For  the  cavity  analysis  the  following 
assumptions  were  made: 

1.  The  properties  or*  , e*  ,and  P\  are 
independent  of  temperature  (this  has  been  shown 
by  experiment  to  be  an  accurate  assumption  for 
most  materials). 


2.  For  infrared  wavelengths  (X  > 2.5  ym) 
and  for  solar  irradiation  wavelengths  (X  < 2.5  ym) 
spectral  directional  values  for  emissivity  may 
be  calculated  from  simple  correlation  formulas, 
which  were  based  on  electromagnetic  wave  theory 
combined  with  available  experimental  data  (an 
example  is  shown  in  Figure  6). 


Figure  6 Total  Directional  Solar  Absorptivity  of  Silver/Teflon 


3.  The  surfaces  are  smooth  and 
isotropic,  so  that  the  bidirectional 
reflectivity  has  its  maximum  in  the  specular 
direction  and  diminishes  monotonically  for 
directions  farther  and  farther  away. 

Surface  Description  and  Ray  Tracing 

In  the  computer  program  all  surfaces 
are  described  in  vectorial  form  (Reference  [3]), 
where  the  vector  components  are  polynomials  in 
either  one  of  two  perpendicular  surface 
parameters.  This  description  allows  for  curved 
or  flat  Mquasi-three-dimensional‘’  surfaces; 
i.e.,  surfaces  for  which  there  exists  a plane 
such  that  the  projection  of  the  surface  on  this 
plane  is  a (curved  or  straight)  line. 

The  emission  and  tracing  of  energy 
bundles  was  carried  out  by  using  standard 
techniques;  i.e.,  by  comparing  random  number 
with  probabilities  for  emission  location, 
wavelength,  and  direction,  as  well  as  for 
absorp tivities  and  reflectivities.  In  order  to 
minimize  the  required  computer  time,  a number  of 
timesavers  were  devised,  tailored  especially  to 
the  payload  bay  door-radiator  cavity,  which  are 
reported  in  greater  detail  elsewhere  (Reference 
£41.) 

Results 

In  order  to  calculate  net  heat  rejection 
rates  from  the  deployed  panels  of  the  Space 
Shuttle  Orbiter  while  it  is  in  orbit  around  the 
earth,  the  exchange  factors  in  Eq.  (1)  must  be 
determined;  i.  e.  , the  absorbed  fractions  of 
(infrared)  emission  from  all  subsurfaces  and  of 


482 


solar  and  planetary  irradiation  entering  the 
cavity  through  the  openings.  For  comparison 
with  limited  experimental  data  (Reference  [5]) 
the  cavity  was  broken  up  into  a relatively  small 
number  of  isothermal  strips,  as  shown  in  Figure 
5. 


significant  self-irradiation,  which  the 
experiment  neglects.)  Not  surprisingly,  the 
TRASYS  results  are  also  fairly  accurate  for 
infrared  emission,  as  the  reflectivity  of  the 
silver-backed  Teflon  coating  is  low  in  this 
wavelength  range.  In  the  Monte  Carlo 


Table  1 Radiative  Exchange  Factors  JF/_^y  between  Zones  of  Panel/Door  Cavity  (Emitting  Zone  at  80° F) 


From  strip  no. 
to 

(1-1) 

(2-1) 
+ (3-1) 

(5-1) 

(5-2) 

(5-3) 

(5-4) 

(4-1) 

(6-1) 

(6-2) 

(6-3) 

(64) 

Space 

Experiment  (EX) 

0.298 

0.306 

0.421 

0.397 

0.422 

0.481 

0.185 

0.168 

0.245 

0.480 

0.799 

Monte  Carlo  (MC) 

0.295 

0.288 

0.397 

0.414 

0.454 

0.519 

0.184 

0.178 

0.277 

0.495 

0.801 

TRASYS 

0.181 

0.421 

0.438 

0.441 

0.473 

0.552 

0.158 

0.210 

0.321 

0.527 

0.819 

„ n EX 

_ 

(0.019)a 

(0.013) 

(0.015) 

(0.013) 

(0.009) 

0.324 

(0.018) 

(0.002) 

(0.001) 

(0.002) 

0.013 

0.003 

0.008 

0.016 

0.016 

0.011 

0.296 

0.018 

0.000 

0.000 

0.000 

(2-1)  EX 

(0.025) 

_ 

(0.043) 

(0.036) 

(0.020) 

(0.012) 

0.164 

0.090 

(0.002) 

(0.001) 

(0.002) 

+ (3-1)  MC 

0.004 

0.191 

0.049 

0.044 

0.024 

0.017 

0.135 

0.077 

0.003 

0.000 

0.000 

,,  n EX 

(0.021) 

(0.054) 

- 

(0.032) 

(0.020) 

(0.013) 

0.217 

0.224 

(0.042) 

(0.002) 

(0.003) 

MC 

0.017 

0.065 

0.019 

0.018 

0.014 

0.014 

0.202 

0.229 

0.039 

0.003 

0.000 

,,  7\  EX 

(0.037) 

(0.068) 

(0.049) 

- 

(0.019) 

(0.013) 

0.143 

0.285 

0.180 

0.035 

(0.003) 

(5'2)  MC 

0.041 

0.080 

0.027 

0.010 

0.010 

0.009 

0.126 

0.293 

0.200 

0.031 

0.003 

(0.045) 

(0.053) 

(0.042) 

(0.027) 

- 

(0.019) 

(0.028) 

0.127 

0.306 

0.170 

0.026 

(5'3)  MC 

0.060 

0.069 

0.030 

0.012 

0.010 

0.009 

0.027 

0.138 

0.294 

0.179 

0.028 

EX 

(0.045) 

(0.045) 

(0.039) 

(0.026) 

(0.026) 

- 

(0.005) 

(0.033) 

0.130 

0.274 

0.139 

(54)  MC 

0.059 

0.060 

0.039 

0.018 

0.013 

0.011 

0.008 

0.031 

0.150 

0.266 

0.154 

ran  EX 

0.518 

0.204 

0.214 

0.093 

(0.013) 

(0.002) 

- 

(0.021) 

(0.006) 

(0.001) 

(0.000) 

(4*°  MC 

0.490 

0.162 

0.194 

0.079 

0.011 

0.002 

0.021 

0.003 

0.000 

0.000 

0.000 

EX 

(0.024) 

0.091 

0.178 

0.151 

0.047 

(0.009) 

(0.017) 

- 

(0.012) 

(0.004) 

(0.001) 

(6*!)  MC 

0.023 

0.081 

0.184 

0.159 

0.050 

0.008 

0.003 

0.012 

0.010 

0.002 

0.000 

,,  K EX 

(0.005) 

(0.004) 

(0.059) 

0.166 

0.200 

0.061 

(0.008) 

(0.021) 

- 

(0.013) 

(0.004) 

(6*2)  MC 

0.000 

0.002 

0.053 

0.183 

0.194 

0.072 

0.000 

0.017 

0.013 

0.007 

0.002 

(0.004) 

(0.003) 

(0.004) 

0.048 

0.165 

0.191 

(0.003) 

(0.009) 

(0.019) 

- 

(0.007) 

(6*3)  MC 

0.000 

0.000 

0.001 

0.045 

0.165 

0.192 

0.000 

0.005 

0.011 

0.010 

0.006 

EX 

(0.010) 

(0.007) 

(0.007) 

(0.005) 

0.033 

0.129 

(0.001) 

(0.003) 

(0.007) 

(0.009) 

- 

(64)  MC 

0.000 

0.000 

0.000 

0.002 

0.040 

0.138 

0.000 

0.000 

0.004 

0.008 

0.007 

Sum  of 

experiment 

1.032 

0.854 

1.069 

0.996 

0.978 

0.939 

1.095 

0.999 

0.951 

0.990 

0.986 

flValues  in  parentheses  were  obtained  from  TRASYS  (Reference  [ 6 ] ) . 


Table  1 shows  a comparison  of  calculated 
exchange  factors  between  strips  with 
experimental  data.  In  both  cases  the  emitting 

strip  was  assumed  (or  held)  at  the  constant 
temperature  of  27°C  (80°F).  The  exchange 

factors  from  strips  to  space  are  the  fractions 
of  emitted  energy  that  leave  the  cavity  through 
all  openings,  front,  rear,  and  sides.  Also 
included  in  Table  1 are  values  for  the  exchange 
factors  to  space  as  obtained  by  the  TRASYS 
computer  code  (Reference  [6]),  which  assumes 
plane  strips  with  gray,  diffuse  surface 
characteristics.  In  general,  the  agreement 
between  the  experimental  exchange  factors  and 
the  results  obtained  by  the  Monte  Carlo  method 
is  excellent,  in  spite  of  the  fact  that  only 
scarce  surface  property  data  were  available. 
Much  of  the  small  discrepancies  may  be 

attributed  to  experimental  inaccuracies.  For 
small  exchange  factors  the  experiment  became  too 
unreliable,  so  the  TRASYS  data  were  used.  The 
experimental  uncertainty  is  illustrated  by  the 
last  row  in  Table  1,  which  shows  that  the  sums 
of  the  experimental  exchange  factors  do  not  add 
up  to  unity  as  they  should,  indicating  at  least 
a 10%  error  margin.  (The  error  is  larger  in  the 
case  of  strip  (2-1)  + (3-1)  because  of 


calculations,  an  average  of  about  20,000  energy 
bundles  were  traced  from  each  emitting  strip. 
Duplicate  runs  with  different  sets  of  random 
numbers  showed  that  the  results  can  be  assumed 
accurate  to  + 0.005,  well  within  experimental 
accuracy.  With  such  a tolerance  it  took 

approximately  1 min.  to  calculate  the  exchange 
factors  from  one  strip  to  all  strips  and 
openings,  using  a Univac  1110  computer.  This 
amount  of  computer  time  compares  favorably  with 
the  time  used  by  the  less  sophisticated  TRASYS 
program,  which  employs  fourth-order  integration. 

A summary  of  solar  irradiation  exchange 
factors  is  shown  in  Figures  7 and  8.  In  these 
calculations  it  is  assumed  that  the  sun  rays  are 
parallel  to  the  sides  of  the  cavity  (i.e., 
perpendicular  to  the  Shuttle  axis)  so  that  all 
insolation  enters  through  the  front  openings. 
The  solid  lines  show  exchange  factors  calculated 
with  absorptivi ties  obtained  from  the  previously 
discussed  correlation  and  bidirectional 
reflectivities  that  direct  about  99%  of  all 
reflected  energy  into  a cone  of  3°  half-angle 
around  the  specular  direction,  as  indicated  by  a 
few  experimental  data  for  silver- Teflon.  The 

agreement  with  experiment  is  fairly  good, 
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especially 


if  one  considers  that  the  high 


RADIATOR  FIN  OPTIMIZATION 


SUN^DOOR 


SUN  ANGLE  y 

Figure  7 Fractions  of  Incident  Solar  Flux  Absorbed  by  Bay  Door 


Figure  8 Fractions  of  Incident  Solar  Flux  Absorbed  by  Rejector 
Panel 

reflectivity  of  the  surface  (*v90%)  tends  to 
amplify  small  inaccuracies  in  the  data  for 
reflectivities  and  geometry.  It  is  interesting 
to  note  what  happens  to  the  values  of  the 
exchange  factors  if  the  surface  is  a purely 
specular  of  a purely  diffuse  reflector.  In  the 
case  of  purely  specular  reflection  the  results 
practically  coincide  with  the  actual  reflection 
pattern,  and  are  therefore  not  displayed 
separately.  For  purely  diffuse  reflection  the 
absorption  rates  are  reduced,  as  is  the 

dependence  on  solar  incidence  angle.  This  is 
shown  by  the  dashed  lines.  The  experimental 
data  seem  to  follow  a diffuse  reflection 

pattern,  but  with  higher  absorptivities.  This 
suggests  that  in  the  experiment  (Reference 
[5])not  enough  care  was  taken  to  keep  the 
surfaces  free  of  dust  or  other  contaminants, 
which  would  tend  to  increase  absorptivity  and 
make  reflection  more  diffuse.  In  the  Monte 
Carlo  calculations  about  10,000-20,000  energy 
bundles  were  traced  for  each  solar  incidence 
angle.  Computer  time  on  the  Univac  1110  was 
again  on  the  average  about  1 min.  for  each 
incidence  angle. 


The  radiator  panel  design  is  primarily 
based  on  design  criteria  other  than  thermal. 
Structural  requirements  dictate  a panel  face 
sheet  and  honeycomb  thickness  greater  then  would 
be  required  for  weight  optimum  heat  rejection. 
The  coolant  loop  hydraulic  requirements  limit 
the  allowable  panel  pressure  drop  and  hence  set 
the  tube  size.  The  only  variable  available  for 
weight  optimizing  heat  rejection  is  the  tube 
spacing  or  number  of  tubes  on  the  panels.  The 
forward  panel  (radiation  from  two  sides)  tube 
arrangement  also  presents  an  opportunity  for 
optimizing  heat  rejection.  As  shown  in  Figure 
4,  the  tubes  on  opposite  face  sheets  are 
staggered  to  allow  heat  transfer  from  the  tube 
through  the  honeycomb  to  the  opposite  face 
sheet.  This  effectively  increases  the  radiation 
fin  efficiency  by  raising  the  average  radiation 
temperature . 

Tube  Spacing 

The  tube  spacing  or  number  of  tubes  on 
the  panel  determines  the  radiation  fin 
effectiveness.  As  the  number  of  tubes  is 
increased,  the  fin  effectiveness  and  hence  heat 
rejection  are  increased  but  panel  weight  is  also 
increased.  Radiation  fin  effectiveness  of  the 
forward  and  aft  honeycomb  layup  fin  was 
determined  from  a two  dimensional  thermal  model 
which  considers  heat  transfer  perpendicular  to 
the  tube  direction  and  between  the  face  sheets. 
The  thermal  models  were  verified  by  element  and 
full  scale  prototype  test  data.  Figures  9 and 
10  show  the  variation  in  fin  effectiveness  with 
the  number  of  tubes. 


RADIATION  TSINK  = “ 18°C  (0°F) 

EFFECTIVENESS 


RADIATION  TSjNK=  -18°C  (0°F) 
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Tube  Size 


The  radiator  tube  size  is  selected  to 
meet  the  panel  pressure  drop  requirements  and  to 
provide  a minimum  temperature  drop  between  the 
fluid  and  the  tube.  Due  to  the  relatively  low 
thermal  conductivity  of  R-21,  the  flow  must  be 
in  the  turbulent  region  to  provide  adequate  heat 
transfer  coefficients.  Figure  11  shows  the 


allowable  tube  diameters  as  a function  of  the 
number  of  radiator  tubes.  A somewhat  arbitrary 
criteria  of  a 1°C  temperature  difference 
between  the  fluid  and  tube  is  used  in  this 
analysis.  As  indicated,  the  range  of  allowable 
diameters  is  narrow,  and  at  least  26  tubes  are 
required  to  meet  both  the  pressure  drop  and  heat 
transfer  criteria.  For  the  heat  rejection 
optimization  study  a baseline  design  was 
established  and  variations  were  considered  to 
determine  their  effect  on  weight  and 
performance.  The  relationship  between  pressure 
drop,  tube  diameter  and  number  of  tubes  is  given 
by:  . . 


4p  - f 

where 


rwl,75i- 

fr_L_ 

ir 1 i 

L Bk-75J' 

Iv-^J 

- tube  pressure  drop 


w = tube  flow  rate 
N = number  of  tubes 


[M 


D = tube  diameter 


The  fluid  to  tube  area  for  heat  transfer  times 
the  convection  heat  transfer  coefficient  (hA)  is 
a function  of  the  number  of  tubes  to  the  0.2 
power  and  the  inverse  of  the  tube  diameter  to 
the  0.8  power, 


for  turbulent  flow.  Thus  the  effect  of  the 
number  of  tubes  on  hA  is  found  by  finding  the 
tube  diameter  from  the  pressure  drop 
relationship  and  the  change  in  hA  from  the  above 
relationship . 


Heat  Rejection 

A system  thermal  model  that  had  been 
verified  by  correlation  with  test  data  was  used 
to  optimize  the  tube  spacing.  Appropriate  fin 
effectiveness  and  hA  products  for  various  tube 
spacings  were  input  to  the  model  to  determine 
system  heat  rejection.  Panel  weight  variations 
with  the  number  of  tubes  were  used  to  determine 
the  heat  rejection  rate  per  unit  weight 
( BTU/hr-lb) . Both  6 panel  and  8 panel  systems 
were  considered.  The  heat  load  and  orbital 
attitudes  were  chosen  such  that  the  heat 
rejection  requirement  exceeds  the  system 
capacity.  This  prevents  radiator  bypass  and 
provides  heat  rejection  optimization  under 
conditions  which  require  maximum  radiator 
perf  ormance. 

HEAT  REJECTION  (Btu/hr-lb) 


system  heat  F,flure  12  Radiator  System  Performance 

REJECTION 

(Btu/hr-lb) 


Figure  13  Radiator  System  Performance 
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Figures  12  and  13  show  the  system  heat 
rejection  per  unit  weight  as  a function  of  the 
number  of  tubes  on  the  forward  panel  and  aft 
panel  respectively.  It  is  seen  that  for  both 
the  six  panel  and  eight  panel  systems  the 
optimum  number  of  forward  panel  tubes  is  70. 
However,  the  use  of  70  tubes  required  a 
non-standard  tube  inside  Diameter  of  3.269  mm 
(0.1287  in).  A 68  tube  forward  panel  allows  the 
use  of  a stock  A. 7625  mm  0D  tube  with  0.71  mm 
wall  thickness  (3/16  x .028  in)  and  provides  a 
near  optimum  design.  The  cost  and  schedule 
aspects  of  using  stock  tubing  overrides  the 
slight  performance  gain  of  the  optimum  design 
panel,  thus  the  68  tube  forward  panel  design  was 
selected . 

The  aft  panel  optimization  (Figure  13) 
indicates  optimum  performance  in  the  range  of  26 
to  29  tubes.  Again,  based  on  the  criteria  of 
using  stock  tubing  (6.35  mm  0D  with  0.889  mm 
wall  thickness)  (1/4  X .035  in.)  a 26  tube  aft 
panel  design  was  selected.  It  should  be  noted 
that  both  the  forward  and  aft  panel  stock  tubes 
are  chemically  milled  to  the  outer  diameters 
shown  on  Figure  4 as  a weight  savings  measure. 

SYSTEM  PERFORMANCE 

Performance  of  the  radiator  system  can  be 
predicted  with  a high  degree  of  accuracy  using 
large  scale  computer  routines.  Results  from  the 
foregoing  analysis  were  used  to  develop  a 
thermal  model  of  the  radiator  system  which 
includes  Orbiter  structure  with  which  the 
radiators  interchange  energy  by  thermal 
radiation.  The  techniques  used  and  the  results 
of  these  analyses  are  reported  in  detail  by 
Benko  (References  [7]  and  [8])  and  Howell  and 
Williams  (Reference  [2]). 

Temperature  Control 

Each  of  the  two  R-21  flow  loops  in  the 
Orbiter  contains  a Flow  Control  Assembly  (FCA) 
which  performs  temperature,  fluid  flow,  pressure 
drop  control  and  fault  detection  functions. 
Incorporating  all  of  these  control  requirements, 
some  of  them  quite  unusual  was  a major  challenge 
in  hardware  design.  One  such  function: 
temperature  control  of  the  coolant  is 
accomplished  by  simple  bypass  of  the  radiators, 
as  shown  schematically  in  Figure  2.  Electronic 
controllers  regulate  the  Flow  Control  Valve 
position  to  maintain  the  mixed  outlet 
temperature  at  either  3.3  + 1°C  or  14.4  + 
1°C,  as  selected  by  the  crew.  Specifically, 
the  temperature  control  approach  is  a closed 
loop  control  system  with  velocity  damping.  The 
flow  control  valve  is  driven  by  a stepping  motor 
with  approximately  2200  steps  from  the  full 
radiator  flow  to  full  radiator  bypass 

positions.  The  stepping  rate  to  the  valve  motor 
is  a function  of  the  temperature  error  and  the 
rate  of  change  of  the  temperature  error  as  given 
by  the  equation: 

P = Ge  Te  + Gr  lllii 


where  P 

= 

the  pulse  rate  or  stepping 
rate,  pulses/sec. 

Ge 

= 

The  temperature  error  gain 

= 

11  Steps/sec-°C  (6  steps/ 
sec-F)  nominally 

Gr 

' 

The  temperature  rate  of 

change  gain 

s 

25  Steps/°C  (14  steps/  °F 
nominally 

Te 

s 

The  sensed  temperature  error 

8 

Tsen-Tset 

Tsen 

- 

Sensor  temperature, 

Tset 

The  set  point  temperature, 
3.3°C  or  14 .4  °C  (38  °F  or  57 
°F)  by  crew  selection 

pulse  rate 

has  the  limitations  of  24  pulses 

per  second  maximum  and  a dead  band  of  zero 
pulses  per  second  when  a pulse  rate  of  less  than 
approximately  1.0  pulses  per  second  is  called 
for.  The  rate  of  change  term,  Gr,  was  added  to 
the  control  function  when  the  requirement  was 
imposed  to  maintain  the  sensor  temperature, 
Tsen,  above  the  fault  temperature  of  0.6  + 

0.3®C  (33  + 0.5°F)  when  a rapid  decrease  in 
bypass  temperature,  Tg  (see  Figure  2)  occurs. 
This  rapid  decrease  in  the  bypass  temperature 
could  be  as  high  as  1.4°C/sec  (2.5°F/Sec) 
given  by  the  following  relation 

Tb  - Tbo  - 20  (1-e  -t/8)  [71 

where  Tfi  = radiator  inlet  temperature 
during  d own  ramp  , °F, 

Tg0  = Radiator  inlet  temperature  at 
start  of  downramp  , °F. 
t“  time  from  start  of  downramp 
seconds. 

This  severe  transient  requirement  also  imposed 
restrictions  on  two  other  components  in  the 
control  circuit.  The  flow  control  valve  was 
designed  to  counter  the  nonlinear  variations  of 
the  system  flow  characteristics  to  provide  a 
linear  flow  split  that  is  within  a band  of  15% 
of  full  flow  and  with  a local  slope  of  one  half 
to  twice  the  linear  slope.  In  addition  the 
temperature  sensor,  shown  in  Figure  2 was 
required  to  have  a low  time  constant.  The 
temperature  sensor  is  mounted  in  a dry  well 
(could  be  removed  without  fluid  loss)  which  is 
filled  with  thermal  grease  (Eccotherm  TC-4) . 
The  resulting  time  constant  has  been  estimated 
by  correlating  test  data  to  be  2.74  seconds  for 
the  time  constant  following  a 1.13  second  time 
delay  for  the  fluid  temperature  change  at  the 
control  valve  to  reach  the  temperature  sensor. 

There  are  two  valves  in  each  FCA  in 
addition  to  the  Flow  Control  Valve.  The  Bypass 
Valve  is  plumbed  in  parallel  with  the  Flow 
Control  Valve  with  the  Bypass  Valve  in  the 
dominant  position.  During  launch  and  re-entry 
the  bypass  valve  is  manually  activated  by  the 
crew  to  divert  flow  around  the  radiator 

subsystem.  The  mode  control  valve  is  a 
pre-launch,  ground  operated  hand  activated 
on-off  valve  which  is  used  to  set  the  pressure 
drop  characteristics  of  the  flow  control  valve 
bypass  line  according  to  whether  six  or  eight 
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radiators  are  being  used  (to  satisfy  a 
requirement  that  the  R21  loop  flowrate  be  lower 
for  eight  panels  than  for  six).  The  pressure 
drop  requirements  are  shown  in  Table  2 for  the 
six  panel  and  eight  panel  system  configurations. 

TABLE  2 ALLOWABLE  FCA  PRESSURE  DROP 


FLOWRATE  A P ACROSS  FCA  - kPa(psi) 


MODE 

g/s  ( lb  /hr ) 

MAX 

MIN 

6 PNLS 

283  (2350) 

186  ( 27.1) 

69  (io.o) 

6 PNLS 

307  (2550) 

219  (31.9) 

89  (13.0) 

8 PNLS 

301  (2500) 

137  (20.0) 

62  ( 9.1) 

8 PNLS 

325  (2700) 

160  (23.3) 

72  (10. U) 

BYPASS 

331  (2750) 

21  ( 3.0) 

— 

The 

Flow  Control 

Valve  also 

required 

special  flow/pressure  drop  characteristics  to 
meet  the  system  pressure  drop  needs.  Figure  14 
shows  the  valve  pressure  drop  versus  valve 
position  designed  into  the  valve  by  shaping  of 
the  poppet  to  provide  the  pressure  drop 
control . 

pressure  325  g/sec  (2,700  Ib/hr)  R - 21  pressure 

DROP  (kPa)  DROP  (psi) 


The  fault  detection  system  on  the  FCA 
monitors  the  temperature  of  the  controlled 
outlet  fluid  temperature  and  automatically 
switches  the  bypass  valve  to  full  bypass  if  the 
temperature  goes  below  0.6  + 0.3°C  (33  + 0.5 

°F).  The  FCA  also  provides  for  performance 
monitoring  which  supplies  an  electrical  signal 
proportioned  to  the  FCA  outlet  temperature.  The 
signal  is  a DC  voltage  which  is  zero  VDC  at 
-1°C  (30°F)  and  is  5 VDC  at  18°C  (65°F) 
The  bypass  valve  positions  are  also  indicated  by 
the  performance  monitoring  system. 

FLOW  TUBE/ STRUCTURE /THERMAL  CONTROL  COATING 
INTEGRATION 

Thermal  control  coating  selection  is  a 
significant  challenge  for  Space  Radiators.  The 
desired  charactert ics  for  a space  radiator 
coating  are  high  energy  emission  (low 
reflectance)  in  the  infrared  (or 

low-temperature)  spectrum  while  being  highly 


reflective  in  the  solar  spectrum.  The  coating 
also  needs  to  be  unaffected  by  the  space 
environment . 

The  two  general  types  of  coatings  used  for  space 
radiators  are  white  paints  and  optical  solar 
reflectors.  At  the  time  of  the  Orbiter  radiator 
development,  the  optical  solar  reflector 
silver-backed  Teflon  was  selected  as  the  best 
available  coating  considering  thermal 
performance,  maintenance,  weight,  life,  and  life 
cost.  A major  development  program  was  required 
to  find  an  adhesive  which  would  satisfactorily 
bond  silver-backed  Teflon  to  structure  over  the 
required  temperature  range  of  -200°C  to 
100°C.  The  selected  adhesive  was  silicone 
based  Permacel  223  . An  autoclave  cure  process 
was  developed  for  using  the  silver-backed 
Teflon's  P223  adhesive  to  aluminum.  The  process 
will  keep  P223  bonded  to  aluminum  over  a 
temperature  range  of  -300°C  to  120°C  in  a 
vacuum. 

While  thermal  studies  were  showing  the 
need  for  adhesively  bonded  silver-backed  Teflon, 
structural  analyses  were  indicating  the  need  for 
a fatigue  resistant  structure  such  as  bonded 
honeycomb.  It  quickly  became  apparent  that 
adhesively  bonding  silver-Tef Ion  to  radiators 
having  closely  spaced  tubes  on  the  outside  of 
the  conductive  fin,  as  would  be  required  on  the 
two-sided  forward  radiators,  would  be 
particularly  time  consuming  and  conducive  to 
unsatisfactory  workmanship.  Thus  a scheme  was 
developed  for  embedding  the  tubes  inside  the 
radiator  honeycomb  layup  to  provide  the  smooth 
surface  for  silver-Teflon  application  shown  in 
Figure  4.  The  smooth  exterior  surface  permits 
the  use  of  vacum  bagging  to  maintain  pressure  on 
the  silver-Teflon  during  the  adhesive  cure 

= process. 

S 

It  was  found  that  using  conventional 
raidator  tubes  with  a flange  which  bonds  to  the 
radiator  skin  was  difficult  when  the  tube  is 
embedded  in  the  honeycomb  core.  Analyses  showed 
that  standard  round  tubes  could  be  used  if  the 
bond  line  between  the  tube  and  the  skin  could  be 
sufficiently  reduced  and  a conductive  adhesive 
was  used.  A technique  was  developed  for  bonding 
the  radiators  so  the  tube-to-skin  bond  line 
thickeness  would  be  0.08  mm  or  less.  This  gives 
a tube  to  skin  temperature  drop  of  0.5°C, 
under  maximum  heat  rejection  conditions.  This 
compares  favorably  to  other  radiator  tube-to-fin 
attachment  configurations. 

The  conductive  adhesive,  Metlbond  329-7, 
is  loaded  with  aluminum  powder  to  increase  its 
thermal  conductivity.  This  provides  another 
plus  for  the  radiator  honeycomb  structure  since 
the  aluminum  powder  loading  makes  the  adhesive's 
thermal  expansion  coefficient  more  nearly  match 
that  of  aluminum.  This  permits  the  structure  to 
operate  over  a temperature  range  of  -200°C  to 
+175°C  without  delamination  due  to  thermally 
induced  stresses. 
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FLUID  SYSTEM  SEALING 


The  Orbiter  radiator  system  has  a maximum 
allowable  leakage  rate  of  0.03  see  per  second 
(0.0011  lb/hr).  Loss  of  fluid  is  to  be  avoided 
for  the  obvious  reason  that  carrying  make-up 
fluid  is  expensive,  and  the  leaked-out  fluid  may 
contaminate  other  Orbiter  systems  or  payloads. 
All  welded  construction  was  desirable  for  the 
Orbiter  radiator  system  to  eliminate  leakage. 

FLANGE  JOINTS 

Welding  was  not  practical  for  the 
connection  of  the  aluminum  radiators  to  the 
stainless  steel  flex  hoses  between  radiators  as 
shown  in  Figure  15.  Flange  joints  were  selected 


(TYP)  (TYP) 

Figure  16  Radiator  Manifold  Details 


for  this  joint  because  effective  dissimilar 
metal  corrosion  protection  is  easily  provided 
for  them.  The  aluminum  flange  is  anodized  and 
the  stainless  steel  flange  is  passivated,  and 
both  are  coated  with  super  Koropon  except  on  the 
flange  face.  When  the  joint  is  made,  RTV  is 
applied  to  the  interface  region. 

Obtaining  a seal  was  a more  formidible 
challenge  because  of  the  wide  temperature  range 
of  the  radiators  (-130°C  to  120  °C) , and  the 
material  compatibility  problems  associated  with 
R-21.  Teflon  is  the  material  of  choice  for  R-21 
seals;  however,  it  is  not  satisfactory  in  0-ring 
form  for  the  radiator  temperature  range.  Teflon 
omni-seals  were  selected  because  the  spring  in 
these  seals  keeps  the  seal  lips  in  place  over 
the  desired  temperature  range.  In  order  for  the 
Teflon  omni-seal  to  form  a leak-tight  seal,  it 
was  found  that  the  flange  faces  should  be 
finished  with  a tool  that  has  a rotary  motion, 
and  that  the  finish  should  be  in  the  range  of 
32-63  -in.  RMS.  Smoother  finishes,  or  those  in 
which  rotary  motion  of  the  tool  was  not  used 
were  found  to  be  prone  to  leak. 

MANIFOLD  WELDS 

The  numerous  tubes  in  each  radiator  are 
welded  into  manifolds  at  each  end  as  shown  in 
Figure  16.  The  flow  tubes  are  6061-T6  Aluminum 
Alloy  to  provide  the  yield  strength  required  due 
to  bending  of  the  radiators.  Welding  of  the 
flow  tubes  into  the  manifolds  produced  "hot 
short"  cracks  in  the  manifolds  with  all  manifold 
materials  and  welding  techniques  tried.  Finally 
a suitable  material.  Aluminum  Alloy  5083,  was 


found.  However,  5083  is  not  commercially 
available  in  seamless  tube  form.  And,  while  it 
generally  has  excellent  corrosion 
characteristics,  it  is  susceptible  to  stress 
corrosion  if  improperly  thermally  conditioned. 
Vought  bought  a billet  of  5083  and  had  it 
processed  into  2.22  cm  (7/8-inch)  O.D.  manifold 
tubing  (Reference  [9]).  This  tubing  completely 
eliminated  welding  problems  throughout  the 
program . 

LEAKAGE  DETECTION 

Proving  that  leakage  of  the  radiators  was 
within  the  allowable  range  was  a significant 
challenge.  Halogen  detectors  are  used  with 
great  success  to  verify  there  is  no  leakage  from 
the  flange  joints;  however,  it  is  difficult  to 
obtain  a quantifiable  leakage  rate  from  a large 
structure  such  as  the  radiators  with  this 
technique.  Vought  developed  a technique  for 
measuring  leakage  from  an  entire  radiator.  This 
was  done  by  calibrating  a gas  Partial  Pressure 
Analyzer  reading  with  a known  R21  leak  rate 
within  the  thermal- vacuum  chamber  used  for 
radiator  acceptance  testing  (Reference  [10]). 
Most  of  the  radiators  have  a leakage  rate  below 
the  minumum  detectable  level  of  10“^  scc/sec. 

LOADS  AND  STRESS  ANALYSIS 

The  Orbiter  lift-off  acoustic  noise 
environment  has  unusually  high  energy  levels  at 
low  frequency;  in  the  10-20  Hz  range  in  which 
the  large  radiators  are  highly  responsive. 
Determining  the  loads  and  stresses  on  the 
radiator  was  a major  challenge  involving 
state-of-the-art  finite  element  computer 
analysis  which  is  beyond  the  scope  of  this  paper 
to  describe.  However,  The  importance  of  this 
challenge  was  of  such  magnitude  that  it  must  be 
mentioned  in  any  compilation  of  Radiator  Design 
Challenges. 

Dynamic  response  models  of  the  entire 
Orbiter  (generated  by  Rockwell  International) 
were  combined  with  models  of  the  radiators  to 
determine  radiator  loads.  These  loads  were  then 
used  to  size  radiator  structural  components. 
These  are  reported  in  References  [11]  and  [12], 
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and  and  to  very  limited  extent  in  Reference 

(2).  The  work  of  Mr.  Ron  Ott  (deceased , 1981) , 
was  particularly  significant  in  the  structural 
design  of  the  radiator  systems. 


CONCLUSIONS 

The  Orbiter  radiator  system  has  performed 
flawlessly  as  expected  during  the  first  six 
Shuttle  flights.  During  execution  of  the 
program  all  major  milestones  and  all  hardware 
deliveries  were  met  on  schedule.  In  addition, 
the  program  was  completed  under  the  planned 
budget.  This  factor,  when  considered  together 
with  those  technical  challenges  discussed 
herein,  illustrates  the  extent  to  which  the 
challenges  of  Space  Shuttle  Orbiter  Radiator 
design  were  satisfied.  The  well-conceived  and 
executed  space  radiators  research  and 
development  programs  carried  out  in  the  late 
1960's  and  early  1970's  provided  the  basis  for 
the  success  of  the  Orbiter  Radiator  program. 
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ABSTRACT 


A review  of  STS-1  processing  is  presented  as  a reference  for  Shuttle  processing  time  and  the  mag- 
nitude of  the  associated  modifications,  discrepancies,  technical  requirements,  and  ground  systems 
activities.  STS-1  processing  provided  the  basis  from  which  a plan  to  perform  operational  turnaround 
was  established.  Turnaround  processing  for  Launch  and  Landing  are  treated  separately  to  depict  more 
clearly  the  progress  made  to  reduce  turnaround  time  and  manhours  expended. 

Turnaround  time  was  reduced  from  187  days  for  STS-2  to  60  days  for  STS-7  and  landing  turnaround 
was  reduced  from  14  days  to  5 days.  Modifications  were  reduced  from  114  to  51.  Requirements  changes 
for  launch  readiness  verification  were  reduced  from  536  to  107.  Special  tests  or  inspections  were 
reduced  from  292  to  52.  Anomalies  resolved  concurrent  with  processing  were  reduced  from  13,000  to 
4,000. 


While  total  turnaround  time  was  reduced,  the  relative  time  spent  in  the  Orbiter  Processing  Facil- 
ity (OPF)  continue  to  be  one  half  of  the  turnaround.  Integration  in  the  Vehicle  Assembly  Building 
(VAB)  is  about  10  percent  of  the  flow,  and  Launch  Pad  operations  comprise  40  percent  of  the 
turnaround. 

As  turnaround  operations  matured,  the  volume  of  work  and  turnaround  time  steadily  decreased.  The 
work  force  has  matured  and  has  demonstrated  the  capability  to  perform  planned  and  contingency  opera- 
tions. The  turnaround  program  is  fast  approaching  the  goal  of  becoming  operational.  The  challenge 
ahead  is  to  transition  from  a development-dominated  operation  to  a production  oriented  operation. 


INTRODUCTION 


In  the  last  two  decades  many  major  technical  projects  have  been  designed  concurrent  with  the 
planning  of  their  operational  phases.  The  Space  Shuttle  program  exemplifies  the  challenge  of  concur- 
rency, which  is  management  of  a project  while  significant  factors  are  very  dynamic.  Ground  operations 
for  the  Shuttle  Orbiter  flight  test  program  were  planned  during  the  design  and  build  phases  of  both 
the  flight  and  ground  systems.  This  planning  of  ground  operations  before  the  flight  systems  design 
certification  and  qualifications  were  completed  later  necessitated  changes  to  insure  compatibility. 
Facilities  and  support  equipment  were  constructed  before  flight  hardware  had  been  completely  defined, 
and  later  required  changes  as  well. 

Our  progress  toward  achieving  a repetitive  operation  with  reduced  turnaround  time  is  easily 
traced.  The  approach  was  founded  in  the  proven  techniques  of  airline  maintenance  and  aircraft  fabri- 
cation. Maximum  effort  has  been  expended  to  establish  a standard  processing  flow  cycle  that  is  re- 
peated on  each  flight,  while  still  dealing  with  the  peculiar  features  of  payloads  or  flight  anomalies. 
To  accomplish  this,  we  have  carefully  evaluated  requirements  reductions,  efficiency  improvements,  and 
design  changes  that  could  shorten  the  turnaround  and  reduce  the  cost  per  flight.  Each  of  these 
improvements  has  been  carefully  analyzed  to  assure  there  is  no  degradation  in  safety  and  to  assure 
mission  success. 

Requirements  for  ground  processing  are  prepared  by  the  design  centers  and  levied  on  the  opera- 
tional center  by  the  Operations  and  Maintenance  Requirements  Specification  Document  (OMRSD).  These 
requirements  have  been  carefully  analyzed  for  reductions  by  the  design  and  operational  centers 
starting  with  STS-1. 

Important  among  these  reductions  has  been  the  retention  of  hypergolic  propellants  on  the  vehi- 
cle. Implemented  only  after  a careful  review  by  safety  system  engineers,  hypergolic  retention  has 
saved  significant  time  in  the  processing  flow.  No  significant  safety  issue  has  occurred  due  to  this 
operational  improvement. 
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Excellent  progress  has  been  made  in  firming  processing  procedures,  and  this  has  provided  greater 
ground  crew  proficiency  and  efficiency.  Procedures  have  been  subjected  to  post- test  critiques  with 
both  engineering  and  operations  personnel.  These  critiques  have  improved  operational  sequences  and 
eliminated  unncessary  steps. 

Improvements  have  also  been  made  in  simplifying  the  work  documents  from  which  the  technician 
must  work,  allowing  him  to  spend  more  time  on  the  job  and  less  time  obtaining  related  instructions. 
Another  improvement  is  the  provision  of  parts  and  tools  to  the  work  areas  on  a planned  schedule. 

These  improvements,  enhanced  by  the  constant  attention  to  bettering  the  operational  turnaround, 
have  resulted  in  a great  reduction  in  the  expended  manhours  per  flight.  Figure  1 shows  the  reduction 
in  turnaround  days  and  Figure  2 the  reduction  in  manhours  per  flow.  Continued  application  of  these 
techniques  and  improvements  will  allow  the  Shuttle  program  to  achieve  and  exceed  its  cost  per  flight 
objectives. 


STS-1  PROCESSING 


One  of  the  major  challenges  of  the  Design,  Development,  Test  and  Engineering  phase  of  the  Space 
Shuttle  Program  was  to  develop  the  basic  ground  operations  techniques  which  will  be  the  cornerstones 
for  the  operational  era  ground  processing  methods.  Two  major  criteria  must  be  satisfied:  fulfill- 

ment of  the  technical  requirements  of  this  highly  complex  spacecraft  to  certify  its  flightworthiness 
and  accomplishment  of  major  processing  milestones  that  had  been  scheduled  some  months  in  advance. 
Ground  operations  are  conducted  to  support  a traffic  model  of  24  to  30  annual  launches  from  the 
Kennedy  Space  Center  and  6 to  10  launches  from  Vandenberg  Air  Force  Base,  California  by  1990.  These 
criteria  must  be  met  while  still  maintaining  a high  degree  of  flight  safety  and  systematically 
reducing  the  cost  per  flight. 

The  ground  operations  effort  for  STS-1  cannot  be  assessed  as  a measure  of  Orbiter  turnaround 
since  these  activities  focused  almost  entirely  on  certifying  Orbiter  102  for  its  maiden  flight. 

Orbiter  102  arrived  at  KSC  on  March  25,  1979  and  launched  on  April  12,  1981  - 744  days  after  its  ar- 
rival. During  this  two-year  period,  340  modifications  were  made  to  the  Orbiter.  In  addition  to 
these  modifications,  approximately  24,000  thermal  protection  system  tiles  (over-thirds  of  the  total 
number  of  tiles  which  comprise  the  outer  mold  line  of  the  Orbiter)  were  removed,  densified,  and 
reinstalled.  This  period  also  saw  a tremendous  effort  in  the  development,  evaluation,  and  changing 
of  Operations  and  Maintenance  Requirements  Specifications  and  the  development  of  Operations  and  Main- 
tenance Instructions  (OMI's)  to  implement  the  requirements.  One  thousand  four  hundred  thirty-three 
(1,433)  OMI's  were  developed  to  process  STS-1.  These  procedures  contained  almost  250,000  pages  of 
detailed  processing  instructions,  special  instructions  such  as  operational  and  safety  notations,  data 
sheets,  and  emergency  procedures.  Formal  approval  of  2,373  Requirement  Change  Notices  (RCN's),  as 
well  as  numerous  operational  and  safety  requirements,  resulted  in  virtually  all  of  the  OMI's  for 
STS-1  being  revised  prior  to  or  during  their  use.  The  STS-1  task  was  further  complicated  by  the  par- 
allel efforts  of  modification  of  Apollo  program  facilities  and  ground  support  equipment,  and  new  de- 
sign, construction,  and  activation  to  support  the  STS-1  flow.  As  an  indication  of  this  effort, 

9,273  design/modification  packages  were  released  to  support  the  initial  ground  processing  of  the 
Space  Shuttle  vehicle. 

Operational  concepts  on  how  to  process  a reusable  spacecraft  were  developed,  tested,  and  modi- 
fied, and  eventually  resulted  in  vastly  improved  ground  operations.  New  and  modified  processing 
and  launch  facilities  were  evaluated.  A vast  majority  of  the  written  processing  procedures  were 
developed  and  improved  to  support  future  Space  Shuttle  missions.  Basic  methods  of  doing  business 
were  developed  into  plans  and  detailed  into  implementing  instructions  implemented,  and  modified, 
as  required,  to  streamline  operations.  The  major  benefit  derived  from  this  flow  was  the  invaluable 
training  the  processing  team  gained  in  this  first  processing  effort.  The  actual  "hands-on"  experi- 
ence is  resulting  today  in  continuing  processing  improvements  and  lower  cost  per  flight  of  opera- 
tional Shuttle  vehicles. 

This  massive  effort  culminated  on  April  12,  1981,  at  0700:03.9834  EST  when  the  Columbia,  with  As- 
tronauts John  Young  and  Bob  Crippen  aboard,  lifted  off  from  Launch  Complex  39A  and  inaugurated  a new 
era  in  manned  space  flight.  During  its  planned  mission  of  54.5  hours,  the  Columbia  completed  36 
orbits  of  the  Earth  and  landed  at  the  Dryden  Flight  Research  Facility  at  Edwards  Air  Force  Base, 
California  at  1022  PST  on  April  14,  1981.  After  the  flight  crew  egressed,  the  Orbiter  was  towed  to 
the  mate/demate  device  for  safing  of  systems,  reconfiguring  for  transportation,  and  mating  of  the 
Orbiter  to  the  Shuttle  Carrier  Aircraft  (SCA).  Ferry  operations  began  on  April  27  with  SCA  takeoff 
occurring  at  1016  PDT.  After  an  overnight  SCA  refueling  stop,  the  Orbiter  returned  to  KSC  on  April 
28;  just  16  days  after  launch.  This  successful  landing  and  ferry  operation  completed  the  last  phase 
of  the  STS-1  ground  operations. 
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Figure  1.-  STS  Processing  Times  (Working  Days). 


STS-2  2 DAY  MISSION 

12  DAYS  DFRC/FERRY 

STS- 3 8 DAY  MISSION 

8 DAYS  WHITE  SANDS 
SPACE  HARBOR 
DFRC/FERRY 

STS-4  7 DAY  MISSION 

12  DAYS  DFRC/FERRY 

STS-5  5 DAY  MISSION 

6 DAY  DFRC/FERRY 

STS-6  5 DAY  MISSION 

7 DAYS  DFRC/FERRY 

STS-7  6 DAY  MISSION 

0 DAYS  DFRC/FERRY 
(PLANNED) 


MATURATION  OF  SHUTTLE  PROCESSING 


The  ground  operations  for  STS-2  constituted  the  first  Orbiter  turnaround  processing.  It  is  from 
this  processing  flow  that  we  have  developed  the  data  parameters  to  measure  our  performance  toward  our 
goal  of  processing  Orbiters  more  efficiently  at  reduced  cost. 

The  best  measure  of  turnaround  time  is  the  actual  number  of  working  days  required  to  process 
each  flow.  In  examining  the  number  of  work  days  to  process  each  STS  flow,  it  is  obvious  that  the 
data  trend  indicates  a continuous  improvement  in  each  succeeding  turnaround  (Figure  3).  The  apparent 
exceptions  to  this  trend  is  the  number  of  days  required  to  process  STS-5  and  STS-6.  On  these  flows, 
the  Orbiter  spent  more  time  in  ground  processing  than  for  STS-3  and  STS-4.  On  STS-5  this  was  due 
mainly  to  the  first  cargo  installation  with  the  vehicle  on  the  launch  pad.  STS-6,  of  course,  was  the 
first  flight  of  0V-099. 

The  trend  in  the  reduction  of  turnaround  time  is  continuing  on  subsequent  operational  flights. 

The  total  processing  time  for  STS-7  was  only  60  working  days,  with  the  processing  time  for  STS-8 
projected  to  be  approximately  50  working  days. 

The  continuing  decrease  in  processing  time  can  be  attributed  to  the  maturing  of  the  flight  hard- 
ware, decrease  in  the  number  of  requirements  and  procedure  changes,  and  an  increased  proficiency  of 
the  processing  team.  For  turnaround  flows  for  STS-2  through  STS-7,  the  data  indicate  a continuing  de- 
crease in  the  number  of  Revision  Change  Notices,  Master  Change  Records,  Engineering  Orders,  and  Work 
Volume  Indicators  worked  for  each  flow.  The  total  number  of  Work  Volume  Indicators  includes  Discrep- 
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ancy  Reports,  Problem  Reports,  Interim  Problem  Reports,  Operations  and  Maintenance  Instructions,  and 
Test  Preparation  Sheets.  A massive  reduction  in  the  total  number  of  work  items  performed  is  shown. 
Figure  3 illustrates  these  trends. 

Some  of  the  major  requirement  reductions  and  procedure  changes  that  contributed  to  reduced  turn- 
around time  are:  retention  of  residual  OMS/RCS  hypergolic  propellants  on-board  the  Orbiter;  parallel 

loading  of  OMS,  RCS,  Orbiter  APU  and  SRB  APU  propellants;  reduced  flight  control  system  testing; 
deletion  of  dynamic  integrated  tests  in  the  OPF  and  VAB;  deletion  of  wet  countdown  demonstration 
tests;  and  improved  propulsion  system  leak  check  methods. 

In  addition,  a major  contributor  to  the  reduction  in  Work  Volume  Indicators  and  in  processing 
time  is  the  drastic  reduction  in  tile  work.  The  data  indicate  a progressive  trend  in  decreasing  tile 
repair  with  the  exception  of  Flow  5 (Figure  4).  A slight  upturn  of  the  trend  is  due  mostly  to  a 
large  number  of  tiles  suffering  minor  damage  in  a hail  storm  just  prior  to  the  launch  of  STS-4,  with 
this  damage  being  repaired  during  the  STS-5  flow. 

An  important  indicator  of  the  relative  processing  cost  of  each  flow  is  the  total  manhours  worked 
per  flow.  Figure  2 shows  the  total  number  of  manhours  charged  against  each  flow,  with  each  flow 
being  less  than  the  preceding  flow.  Also  indicated  is  the  consistent  decrease  in  the  percentage  of 
total  manhours  devoted  to  modifications  and  tile  work  along  with  the  corresponding  manhours  spent  in 
Operations  and  Maintenance  effort.  This  favorable  trend  is  the  key  to  accurate  cost  estimates  for 
each  flight  in  the  operational  era. 

Recovery  and  ferry  operations  to  return  the  Orbiter  from  the  landing  site  to  KSC  have  continu- 
ously shown  the  same  favorable  data  trend  as  the  KSC  turnaround  (Figure  5).  The  data  show  an  upturn 
in  manhours  to  recover  STS-3,  but  it  must  be  remembered  that  the  STS-3  landing  was  moved  from  DFRF 
to  White  Sands  Space  Harbor,  New  Mexico,  necessitating  transporting  ground  support  equipment  and 
personnel  from  California  to  New  Mexico  in  a relatively  short  time. 
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Figure  3.-  Total  Requirement  Trends. 


Flight  safety  has  been  outstanding,  as  indicated  by  the  fact  that  of  the  six  flights  completed 
as  of  this  writing,  only  STS-2  did  not  complete  its  intended  mission  duration.  The  anomaly  on  that 
mission,  a malfunctioning  fuel  cell,  was  not  related  to  ground  operations,  and  did  not  jeopardize  the 
safety  of  the  crew  or  the  vehicle. 

In  summary,  the  overall  trend  has  been  to  perform  each  ground  turnaround  flow  in  fewer  working 
days  and  with  significantly  fewer  manhours  expended  during  each  successive  flow.  This  overall  reduc- 
tion in  time  and  cost  has  also  been  accompanied  by  a consistently  decreasing  number  of  in-flight 
anomalies  (Figure  6).  The  increase  shown  in  flight  6 anomalies  is  due  to  the  fact  that  the  flight 
was  the  first  of  0V-099.  This  indicator  is  indicative  of  flight  hardware  maturity,  higher  quality  of 
workmanship,  and  increased  understanding  of  the  operation  of  the  flight  hardware. 
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EXTERNAL  TANK  PROCESSING  FROM  BARGE  TO  PAD 


J.  E.  Carpenter* 
Martin  Marietta  Corporation 
External  Tank  Operations 
Kennedy  Space  Center 


ABSTRACT 


The  External  Tank  (ET)  is  off-loaded  at  the  KSC  Barge  Turning  Basin  and  towed  to  the  Vertical  As- 
sembly Building  (VAB),  High  Bay  Transfer  Aisle.  It  is  erected  vertically  and  placed  in  the  ET  Check- 
out Area  of  High  Bay  2 or  4 for  standalone  checkout.  At  the  completion  of  checkout  the  ET  is  trans- 
ferred to  storage  or  to  the  Integration  Area  of  High  Bay  1 or  3 for  SRB  and  Orbiter  Mate.  A Systems 
Integration  Test  is 'performed  with  the  Orbiter  and  SRBs.  Final  movement  is  to  the  Launch  Pad  for 
final  checkout  and  launch. 


INTRODUCTION 


The  External  Tank  serves  a dual  role:  to  provide  the  structural  backbone  of  the  space  Shuttle 
during  launch  operations  and  to  contain  and  deliver  liquid  hydrogen  (LH2)  and  liquid  oxygen  (L02)  pro- 
pellants for  the  Orbiter's  three  main  engines.  The  External  Tank  is  153.8  feet  long  and  27.6  feet  in 
diameter  (Figure  1).  It  weighs  approximately  69,000  pounds  empty  and  when  loaded  with  propellants 
weighs  approximately  1,660,000  pounds.  The  External  Tank  must  accomodate  the  complex  stresses 
created  by  its  own  weight  and  that  of  the  Orbiter  prior  to  launch.  The  flow  of  operations  for  the  Ex- 
ternal Tank  requires  the  precise  accomplishment  of  delivery  and  launch  readiness  events  in  unison 
with  other  space  Shuttle  elements  and  the  Orbiter  turnaround  schedule. 


L02  TANK 


ORBITER 

ATTACHMENTS 


INTERTANK 


FWD  SRB 
ATTACHMENT 


lh2  tank 

LENGTH:  153.8  FT 
DIA:  27.6  FT 

AFT  SRB 
ATTACHMENTS 

Figure  1.-  External  tank. 
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ASSEMBLY  AND  DELIVERY 


The  External  Tank  is  manufactured,  assembled  and  given  final  acceptance  testing  at  the  NASA 
Michoud  Assembly  Facility  (MAF)  in  New  Orleans,  Louisiana.  The  ET  is  mounted  on  an  eight-wheeled 
(Modified  Saturn  SI-B)  transporter  at  the  Michoud  Assembly  Facility  (Figure  2).  This  transporter 
serves  as  the  means  of  moving  the  ET  system  to  and  from  various  points  of  activity  during  delivery, 
and  remains  with  the  system  until  it  is  moved  into  the  VAB  at  KSC. 

The  ET  and  transporter  are  secured  on  a barge  at  Michoud  Assembly  Facility  for  delivery  to  KSC. 
The  barge  transportation  system  was  developed  to  deliver  NASA  Saturn  Stages  to  KSC,  and  has  been 
modified  for  ET  delivery.  The  ET  is  monitored  during  transportation  by  a sensitive  instrumentation 
system.  This  system  monitors  the  ET  for  pressures,  humidity  and  acceleration. 

Upon  arrival  at  the  KSC  Barge  Turning  Basin  the  barge  is  secured  and  ballasted  to  dock  level. 

The  barge  doors  are  opened  and  the  ET  and  transporter  are  prepared  for  towing  to  the  VAB.  The  trans- 
porter is  secured  for  sea  by  four  pedestals  and  tie  down  chains  to  the  barge  deck.  After  removal  of 
the  above  and  overall  visual  inspection  of  the  ET  and  transporter  for  any  apparent  damage,  the  ET  sys- 
tem is  towed  to  the  VAB  and  made  ready  for  ET  transfer  into  a checkout  or  storage  cell. 


ET  SUB-SYSTEM  CHECKOUT 


Operations  for  erecting  the  ET  in  the  High  Bay  begins  with  positioning  of  mobile  access  plat- 
forms to  facilitate  visual  inspection,  disconnection  of  special  shipping  instrumentation,  and 
attaching  forward  and  aft  hoist  slings.  The  ET  will  be  hoisted  from  its  transporter  by  the  250  ton 
and  175  ton  High  Bay  cranes  and  rotated  to  vertical  for  translation  into  a storage  or  checkout  cell. 

In  the  checkout  cell,  a complete  receiving  inspection  is  made  of  all  Thermal  Protection  System 
(TPS)  surfaces,  the  intertank  and  nose  cone  interiors,  and  all  ground  umbilical  connections.  Ship- 
loose  items  and  Ground  Support  Equipment  (GSE)  and  Launch  Processing  System  (LPS)  are  connected. 


ELECTRICAL  SYSTEM  CHECKOUT 


The  electrical  system  provides  the  Operational  Instrumentation  (01)  which  includes  instrumenta- 
tion sensors,  heaters,  a tumbling  subsystem  and  Range  Safety  System  (RSS)  (Figures  3-5).  The 
electrical  system  also  includes  the  ET  cabling,  Orbiter/SRB  cabling,  electromagnetic  compatibility, 
and  lightning  protection.  Electrical  checks  consist  of  installation  of  the  RSS  flight  equipment, 
continuity  and  isolation  checks,  system  power  on,  and  an  end-to-end  systems  test  using  the  LPS  to  sim- 
ulate Orbiter  interfaces.  This  makes  the  checkout  period  as  short  as  possible  through  the  automated 
use  of  display  consoles,  computers,  data  transmission  systems  and  associated  computer  programs. 


PROPULSION  SYSTEM  CHECKOUT 


The  propulsion  system  serves  the  primary  function  of  delivery  oxidizer  and  fuel  to  and  from  the 
propellant  tanks  and  Orbiter  interface  through  17  inch  feedline  disconnects.  The  complete  system  is 
comprised  of  L02  feed  system,  LH2  feed  system,  L02  and  LH2  tank  pressurization,  vent/relief  and  tum- 
bling system,  intertank  and  tank  environmental  control  systems,  and  ET  intertank  carrier  plate  assem- 
bly. Propulsion  system  checkout  consists  of  tank  and  feedline  leak  checks,  relief  and  vent  valve 
checks  and  tank  purge  and  environmental  checks. 


THERMAL  PROTECTION  SYSTEM  (TPS)  CHECKOUT 

The  External  Tank  Thermal  Protection  System  is  to  maintain  the  primary  structure  and  subsystem 
component  within  temperature  limits  during  pre-launch  and  ascent  phases.  It  serves  the  following 
functions:  maintains  L02  and  LH2  boil-off  rates  below  the  vent  valves  capabilities,  contributes  to 

loading  accuracy  and  increased  propellant  densities,  insures  L02  and  LH2  specified  temperatures  at 
the  Orbiter  interface,  minimizes  air  liquefaction  on  the  LH2  tank,  minimizes  air  formation  on  the  ET 
surface  and  minimizes  hard  debris  during  ascent  heating  environment.  Normal  work  on  the  above  system 
at  KSC  is  limited  to  closeout  operations  and  minor  repairs,  although  major  modifications  of  repairs 
can  be  performed  as  necessary.  Checkout  cell  TPS  closeouts  consists  of  the  following:  transporter 

attachment  point,  leak  check  ports,  nose  cone  installation  and  closeout  and  Orbiter  bipod  jack  pad  ' 
closeout. 

With  the  completion  of  the  above  subsystems  checkouts,  the  ET  is  removed  from  the  checkout  cell 
using  the  forward  sling  and  the  250  ton  crane,  and  is  transferred  to  the  storage  or  integration  cell 
(Figure  6). 


499 


Figure  2.-  ET  assembly  transporter. 
ET  TO  SRB  MATE 


Upon  transfer  to  the  Integration  cell,  the  External  Tank  is  lowered  into  position  for  securing 
the  ET/SRB  forward  support  fittings  (Figure  7).  The  ET  is  then  lowered  onto  the  SRB  forward 
fittings.  GSE  guides  and  pins  are  used  to  facilitate  final  seating  alignment,  and  are  then  replaced 
by  the  flight  frangible  bolt/nut  assembly.  At  this  point  the  ET  is  suspended  entirely  from  the  two 
forward  attach  points.  When  the  forward  fittings  have  been  secured,  the  sequence  of  attaching  the 
aft  ET/ERB  stabilizing  struts  begins.  It  begins  with  the  attachment  of  the  right  and  left  diagonal 
struts  to  the  ET  upper  fittings.  One  strut  is  preadjusted  to  length,  the  other  is  adjusted  to  fit. 
The  upper  lateral  struts  are  assembled  to  the  SRB's,  adjusted  to  fit,  and  attached  to  the  upper  ET 
fittings.  The  lower  struts  are  then  similarly  attached  to  the  SRB's  adjusted  to  fit,  and  bolted  to 
the  ET  lower  fittings.  The  ET/SRB  mate  is  completed  by  mating  the  electrical  pull -away  connectors 
located  on  the  two  upper  lateral  struts,  and  by  completing  the  electrical  connections  to  the  forward 
attach  point  frangible  bolt. 

With  the  completion  of  ET/SRB  mechanical  and  electrical  mate  the  upper  lateral  strut  and  forward 
attach  point  cable  fairings  are  installed  and  TPS  closeouts  begin.  TPS  closeouts  consist  of  TPS 
spray  on  the  aft  cable  fairing  and  the  associated  area  around  the  aft  fairing  area. 


ET/ORBITER  MATE 


The  Orbiter  is  erected  and  vertically  aligned  with  the  ET  by  means  of  a sling  set  and  jacks 
attached  to  the  Orbiter.  The  two  aft  ET/Orbiter  structural  interface  points  are  attached  first. 

Both  attachment  points  are  hemisphere  (ET)  to  socket  (Orbiter)  interfaces  with  concentric,  retaining 
bolt/frangible  nut  assemblies.  The  right  interface  is  a fixed  reference  point;  the  left  ET  attach 
point  is  free  floating  laterally  once  the  Orbiter  socket  has  captured  the  ET  hemisphere.  Prior 
to  this  a temporary  adjustable  support  strut  is  used  to  hold  the  left  attach  point  in  position. 

The  two  Orbiter  supplied  interface  bolts  are  installed,  but  final  torquing  is  deferred  until  the 
forward  attachment  is  complete.  Mating  of  the  forward  interface  occurs  by  drawing  the  Orbiter, 
via  the  ET  provided  yoke  fitting,  onto  the  pivotal  bipod.  The  strut  flanged  joints  are  then  bolted 
together.  One  strut  has  an  adjustable  sleeve  that  is  used  to  obtain  the  required  lateral  alignment 
tolerance  (Figure  8). 
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Figure  3.-  Operational  Instrumentation  Figure  4.-  Operational  Instrumentation  sensors 

systems  components.  and  switches. 


With  the  completion  of  mechanical  mate  the  ET/Orbiter  aft  umbilical  disconnects  containing 
the  electrical,  pneumatic  and  fluid  interfaces  are  mated.  Interface  protective  covers  are  removed 
from  the  disconnect  halves.  The  Orbiter  halves  of  the  umbilical  plates  are  extended  from  their 
retracted  position  and  aligned  with  the  halves.  They  are  secured  using  three  flangible  bolt/nut 
combinations  per  assembly. 

At  the  completion  of  mechanical/electrical  pneumatics  and  fluid  mate,  a leak  check  is  performed 
on  the  pneumatic  and  fluid  systems  and  a system  integrated  test  is  performed.  The  STS  is  now 
ready  for  pad  roll  out. 


LAUNCH  OPERATIONS 


The  complete  Space  Shuttle  vehicle  is  moved  from  the  VAB  to  the  Launch  Pad  on  the  Mobile  Launch 
Platform  (MLP).  The  MLP  is  connected  to  the  Launch  Pad  and  its  interfaces  verified.  Concurrently, 
facility  interfaces  are  mated  through  the  ET  intertank  Ground  Carrier  Plate  Assembly  (GUCA).  The 
GUCA  having  been  installed  on  the  intertank  during  ET  checkout,  remains  with  the  ET  throughout  the 
vehicle  integration  flow.  Six  fluid  transfer  lines,  an  electrical  grounding  cable,  two  disconnect 
lanyard  cables,  and  two  support  lanyard  cables  emanating  from  the  launch  complex  are  permanently 
attached  to  the  GUCA.  The  facility  L02  and  LH2,  and  both  ET  tanks  are  purged  with  helium  and 
sampled  to  assure  an  inert  atmosphere  for  propellant  loading. 


FINAL  COUNTDOWN 


The  Space  Shuttle  terminal  countdown  sequence  begins  at  T-5  hours.  Propellant  loading  is  accom- 
plished with  vent  valves  open,  loading  from  the  facility  through  the  Orbiter  into  the  ET.  Both  L02 
and  LH2  are  loaded  simultaneously,  starting  with  a slow  flow  rate  to  precondition  the  lines,  tanks 
and  engines.  The  slow  flow  is  continued  until  the  2%  level  is  reached,  at  which  time  the  flow  rates 
are  increased  to  the  maximum  of  12,000  gpm  for  LH2  and  5,000  gpm  for  the  L02  until  each  of  the  tanks 
contains  98%  of  its  capacity.  The  flow  rates  are  then  reduced  to  provide  a topping  flow  rate  to  100% 
capacity,  followed  by  a still  slower  replenish  flow  continues  until  the  automatic  sequence  starts  at 
T-9  minutes. 
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Figure  5.-  Range  safety  system  block  diagram. 


The  L02  vapors  generated  during  the  loading  and  conditioning  process  are  vented  through  vent  lou- 
vers in  the  nose  cone  and  facility  line  carrying  G02  to  the  umbilical  tower.  LH2  vapors  are  vented 
directly  to  a burn  pond  through  a ET/facility  vent  system  via  the  intertank  ground  umbilical  carrier 
assembly.  This  assembly  also  provides  connections  to  the  pneumatic  lines  for  conditioning  the  nose 
cap  and  intertank  cavity,  monitoring  the  hazardous-gas  detection  system,  and  for  the  actuation  of 
the  vent  valves.  The  L02  and  LH2  tanks  are  then  pressurized,  with  pressurization  occurring  for  the 
L02  tank  at  T-155  seconds  and  at  T-106  seconds  for  the  LH2  tank. 


REFERENCES 


1.  Manual  System  Definition  Handbook,  Space  Shuttle  External  Tank,  MMC-ET-SE25-0,  August 

1980. 
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ABSTRACT 


The  Solid  Rocket  Booster  Retrieval  Program  operates  with  one  primary  objective,  the  recovery  of 
expended  boosters  and  associated  hardware  without  damage  attributable  to  retrieval  procedures.  This 
is  accomplished  by  a retrieval  force  consisting  of  ship's  personnel  and  retrieval  team  members,  each 
of  whom  has  been  trained  and  is  highly  skilled  in  multi-faceted  operations.  The  retrieval  force  is 
equipped  with  two  specially-built,  highly  maneuverable  ships  outfitted  with  parachute  reels,  retriev- 
al cranes,  towing  winches,  large  volume-low  pressure  air  compressors,  SCUBA  diving  gear,  inflatable 
boats  with  outboard  motors  and  diver-operated  SRB  dewatering  devices. 

The  two  ships  are  deployed  in  sufficient  time  to  conduct  an  electronic  and  visual  search  of  the 
impact  area  prior  to  launch. 

Upon  search  completion,  each  ship  takes  station  a safe  distance  from  the  predetermined  impact 
point  initiating  both  visual  and  electronic  search  in  the  direction  of  flight  path,  ensuring  SRB  ac- 
quisition at  splashdown.  When  safe,  the  ships  enter  the  impact  area  and  commence  recovery  of  all 
floating  flight  hardware  which  is  subsequently  returned  to  the  Disassembly  Facility  for  refurbishment 
and  reuse. 


INTRODUCTION 


NASA's  commitment  to  Retrieval  Operations  began  with  and  paralleled  Shuttle  development.  Sev- 
eral feasibility  studies  were  conducted  after  which  contracts  were  initiated  for  Solid  Rocket  Booster 
Retrieval  System  final  design  concept.  The  following  extracts,  NUC  TN  1822,  describe  the  final  de- 
sign concept. 

"The  Naval  Undersea  Center,  San  Diego,  and  the  U.S.  Navy  Supervisor  of  Salvage  formulated  and 
developed  the  final  design  concept. 

For  each  flight  mission  there  will  be  a total  of  fourteen  elements  subject  to  retrieval  con- 
sisting of:  two  SRB  casings,  six  main  parachutes,  two  frustums,  two  drogues  and  two  pilot  para- 

chutes. Each  of  these  elements  is  equipped  with  location  aids  such  as  flashing  lights,  acoustic 
pingers  and  radio-frequency  beacons,  or  are  attached  to  elements  equipped  with  these  devices.  All 
of  the  elements  impact  in  a tear-shaped  footprint  62  nautical  miles  long  by  16  nautical  miles  wide. 

Retrieval  vessels  will  be  stationed  outside  the  impact  area  until  splashdown.  Following  splash- 
down two  fully-equipped  vessels  will  deploy  and  transit  to  the  impact  area.  These  vessels  will  be 
oilfield  tug/supply  vessels  with  all  retrieval  equipment  installed.  The  vessels  will  be  at  least 
170  feet  long  with  a beam  of  not  less  than  30  feet  and  engines  that  will  develop  at  least  3500  h.p., 
twin  screws  and  a bow  thruster  for  station-keeping. 

The  first  items  to  be  retrieved  will  be  the  main  parachutes.  The  retrieval  vessel  will  capture 

the  satellite  float  and  apex  float  of  the  parachute.  A line  will  then  be  attached  to  the  apex  of  the 

parachute  and  the  parachute  will  be  reeled  aboard  the  retrieval  vessel  by  a hydraulically  operated 
power  block  with  a power  grip.  The  power  block  and  grip  will  be  suspended  outboard  of  the  retrieval 
vessel  from  the  boom  of  a deck-mounted  crane.  The  parachutes  will  then  be  reeled  onto  stowage  reels, 
one  main  parachute  per  reel.  The  stowage  reels  will  be  covered  to  protect  the  parachutes  from  sun- 
light . 

The  drogue  and  frustum  will  be  retrieved  next.  The  retrieval  vessel  will  snare  the  pilot  para- 
chute and  attach  a line  to  the  apex  of  the  drogue.  The  drogue  will  be  brought  onboard  the  retrieval 
vessel  using  the  power  block  and  grip  and  stowed  on  the  remaining  parachute  stowage  reel.  The  frus- 
tum will  be  lifted  from  the  water  by  the  drogue  suspension  lines;  the  crane  boom  will  then  be  swung 

to  position  the  frustum  over  dunnage  on  the  deck  of  the  retrieval  vessel.  The  frustum  will  be  lower- 

ed onto  the  dunnage  and  secured  to  cleats  on  the  deck. 

The  last  items  to  be  retrieved  are  the  SRBs. 


♦Manager,  Marina  Operations,  USBI-RP-2 
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A Nozzle  Plug  (NP)  is  used  to  dewater  the  SRB  casing  so  that  the  casing  will  float  in  a log 
mode,  after  which  it  can  be  towed  to  port  by  the  retrieval  vessel.  The  NP  is  an  unmanned,  umbili- 
cal-cable-controlled submersible  vehicle  and  is  controlled  from  a console  located  aboard  the  re- 
trieval vessel.  The  NP  is  launched  by  the  deck-mounted  crane. 

The  NP  docks  with  the  SRB  and  is  locked  into  place  by  three  locking  arms.  Dewatering  of  the  SRB 
is  accomplished  when  air  from  the  retrieval  vessel  is  forced  through  the  pneumatic  hose  of  the  umbili- 
cal into  the  SRB.  The  air  pressure  forces  the  water  out  through  the  SRB  nozzle  (past  the  NP) . When 
sufficient  water  has  been  removed  from  the  SRB,  the  booster  will  become  unstable  and  float  in  a log 
mode . 


An  inflatable  bag  on  the  NP  will  be  inflated,  once  the  SRB  assumes  a horizontal  mode  and  a de- 
watering hose  will  be  deployed.  Additional  air  is  then  forced  into  the  SRB  to  achieve  a pressure 
differential  which  will  force  the  remaining  water  out  of  the  SRB  through  the  dewatering  hose.  The 
umbilical  is  then  detached  prior  to  towing  operations.  A towline  is  attached  to  a towing  pendant 
on  the  nose  of  the  SRB  and  transit  to  the  refurbishment  site  is  begun." 

STS-1  flight  delay  allowed  delivery  of  specially  built  retrieval  vessels  and  provided  time  to 
fully  evaluate  final  design  concepts.  Extensive  training  resulted  in  a cohesive  retrieval  organiza- 
tion which  immediately  demonstrated  Shuttle  cost  effectiveness. 

It  must  be  noted  that  the  first  retrieval  mission  paid  for  the  Parachute  Development  Program, 
SRB  Water  Impact  Testing  and  cost  of  two  retrieval  vessels.  Replacement  value  of  hardware  retrieved 
from  STS-1  thru  STS-5  would  exceed  $216,000,000.00.  (Table  1) 


RETRIEVAL  SHIP  OPERATIONS 


Effective  ship  operations  require  proper  interfacing  of  ship,  ship's  crew,  retrieval  team  mem- 
bers and  procedures  bonded  through  extensive  training  and  observance  of  safety  procedures. 

The  dedicated  retrieval  vessels  with  controllable  pitch  propellers,  transverse  bow  and  trainable 
stern  thrusters  afford  unmatched  maneuverability  and  station-keeping  accuracy.  The  vessels  were 
constructed  and  documented  in  accordance  with  strict  U.S.  Coast  Guard,  American  Bureau  of  Shipping 
and  Federal  Communications  Commission  regulations.  The  vessel  crews  are  dictated  by  the  U.S.  Coast 
Guard  and  must  possess  appropriate  licenses  demonstrating  proper  experience  and  education  levels. 

Basic  ship  handling  techniques  require  fine  honing  to  provide  station  keeping  and  close  in  maneuver- 
ing expertise  essential  for  safe,  efficient  retrieval  activities. 

The  camaraderie  between  ship's  crew  and  retrieval  team  members,  created  by  individual  respect 
and  personnel  cross-utilization,  has  instilled  a 'team'  spirit.  This  'team'  spirit  has  provided  a 
broad  information  exchange  system  providing  coordinated  operational  inputs.  The  retrieval  force  oper- 
ational capabilities  are  clearly  illustrated  by  success  rates  under  diversified  conditions. 


RETRIEVAL  EQUIPMENT  IMPROVEMENTS 


Retrieval  Operations  have  undergone  rapid  change.  The  major  changes  have  occurred  in  the  area 
of  equipment  improvements  and  as  a result,  technical  developments  have  enhanced  overall  mission  effec- 
tiveness. 


Prior  to  STS-1 


Prior  to  STS-1,  the  final  design  concepts  were  thoroughly  tested  during  at-sea  training  using 
a full  scale  Ocean  Test  Fixture  simulating  the  SRB,  a full  scale  model  frustum,  and  full  sized  para- 
chutes. During  these  at-sea  training  missions,  procedures  were  developed  to  retract  the  frustum 
location  aid  antenna,  thereby  eliminating  the  large  wooden  beams  (79K12931  - KSC  DWG)  which  were 
provided  to  eliminate  antenna  damage.  Plywood  was  substituted  as  a base  in  frustum  landing  area 
which  substantially  eliminated  potential  frustum  damage.  The  parachute  retrieval  concept  required 
use  of  two  heavy  idler  rollers  (79K12922  - KSC  DWG).  Parachute  retrieval  operations  demonstrated 
that  a parachute  slide  (nylon)  on  the  deck  could  be  utilized  effectively,  thereby  eliminating  person- 
nel handling  hazards.  The  Ballast  Aerating  Retrieval  Boom  (BARB)  (79K20974  - KSC  DWG)  was  developed 
for  use  if  SRB  nozzle  damage  prevented  use  of  the  NP  and  associated  telescopic  harpoon.  Additionally, 
the  BARB  could  be  utilized  in  a dual  role  for  open  nozzle  towing.  The  BARB  is  a simple,  efficient 
device  constructed  from  aluminum  pipe  and  tubing.  The  main  member  is  20  feet  long  and  1 1/4  inches 
in  diameter.  The  upper  end  is  fitted  with  an  aluminum  cap  and  "0"  ring  seal.  The  lower  end  is 
threaded  to  accept  a 2 inch  ball  valve  and  1 1/2  inch  quick-disconnect  fitting.  The  cross  member 
is  10  feet  long,  2 inches  in  diameter  with  welded  ends.  The  units  are  attached  with  a swivel  fit- 
ting, approximately  5 feet  from  the  main  member  upper  end.  Bungee  cord  is  secured  around  the  swivel 
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fitting  placing  the  unit  under  tension  when  the  cross  member  is  parallel  to  the  main  member.  A 
cable  lanyard  attached  to  the  main  member  cap  and  cross  member  retains  the  device  in  a cocked  posi- 
tion. 


Air  applied  through  the  ball  valve  deploys  the  main  frame  cap  allowing  the  tensioned  cross  mem- 
ber to  re-position  perpendicular  to  the  main  member,  effectively  retaining  the  unit  in  the  SRB  noz- 
zle. 


Prior  to  STS-2 


The  nozzle  plug  (79K15557  - KSC  DWG)  failed  to  operate  satisfactorily  during  STS-1  operations. 
From  a conceptual  viewpoint,  the  remote-control  plugs  designed  and  constructed  for  NASA  fulfilled  the 
requirements  for  a positive  and  hazard  free  retrieval  of  SRBs  from  the  ocean.  In  actual  use  the 
plugs  proved  to  be  maintenance  intensive,  hazardous  to  launch,  and  unreliable  in  performance.  Close 
tolerance,  interlocking  segments  and  general  'layer  cake'  design  prevented  minor  maintenance  unless 
the  total  system  was  desegregated.  The  basic  design  would  not  lend  itself  to  adjustment  or  modifica- 
tion that  would  allow  for  tracking  the  learning  curve;  therefore,  the  nozzle  plugs  remained  inflexi- 
ble from  intended  design  use  and  application.  Based  upon  this  conclusion,  the  Ballast  Aerating  Re- 
trieval Boom  and  divers  were  baselined  for  SRB  dewatering.  Additionally,  an  in-port  Diver  Operated 
Plug  was  developed  and  brought  into  service  to  provide  final  SRB  dewatering  at  Port  Canaveral,  thereby 
facilitating  transit  through  the  Banana  River  to  the  refurbishment  facilities.  The  frustum  landing 
area  was  modified  and  standard  dunnage  (double  thickness  2 x 12  planks)  installed. 

Prior  to  STS-3 


Considerable  problems  had  been  encountered  with  the  final  concept  design  weak  link  (79K19967  - 
KSC  DWG),  which  was  placed  in  series  between  the  SRB  and  towing  vessel  alleviating  damage  to  the  for- 
ward skirt.  NASA  analyzed  the  problem  area  and  designed  a weak  link  that  would  fail  in  tension  and 
bending  modes  while  providing  higher  breaking  strength,  ease  in  handling,  and  low  maintenance. 

Prior  to  STS-4 


Evaluation  of  parachute  retrieval  operations  clearly  illustrated  that  the  existing  parachute 
deck  edge  roller  (79K12922  - KSC  DWG)  caused  additional  and  unnecessary  damage  to  the  parachutes.  At 
this  time,  the  deck  edge  roller  was  replaced  with  a permanent  deck  edge  guide  consisting  of  a 3/4 
round  stainless  steel  pipe  with  vertical  guides.  This  resulted  in  a drastic  reduction  in  damage  and 
provided  for  an  overall  smoother,  safer  parachute  recovery.  Decelerator  sub-system  problems  required 
parachute  flotation  removal;  therefore,  procedures  were  developed  for  detaching  main  parachutes  from 
the  SRBs  at  the  40  foot  release  links.  To  aid  divers  with  detaching,  two  Avons,  rigid  hull  inflat- 
able boats  and  five  diver  propulsion  vehicles  were  added  to  the  retrieval  equipment  inventory.  SRB 
and  frustum  location  aids  had  proved  to  be  marginally  effective  or  had  intentionally  been  deactivat- 
ed; therefore,  12  commercial  emergency  radio  indicator  beacons  with  lights  were  purchased  for  severe 
weather  and  night  station-keeping  operations.  The  accelerated  use  of  divers  required  by  BARB  and  par- 
achute operations  mandated  additional  safety  equipment.  A recompression  chamber  was  obtained  from 
the  Navy  and  installed  on-board  one  retrieval  vessel  for  use  in  the  event  of  diving  accidents.  At- 
sea  operations  in  various  weather  conditions  had  demonstrated  the  concept  design  hawser  was  of  insuf- 
ficient length  creating  situations  that  could  potentially  impart  snap  loads  upon  the  SRB  forward 
skirt.  After  careful  evaluation,  the  nylon  tow  hawsers  were  replaced  with  2000  foot  plastic  covered 
tow  wire.  These  provided  a longer  life  use  cycle,  catenary  in  the  tow  line  to  eliminate  snap  loads 
and  additional  safety  to  deck  personnel. 


Prior  to  STS-5 


Projected  SRB  modifications  and  future  filament  wound  casing  information  indicated  the  center  of 
gravity  would  shift  aft  on  the  casing  necessitating  at-sea  dewatering  capabilities.  Response  to  fu- 
ture requirements  resulted  in  design  and  construction  of  an  at-sea  prototype  Diver  Operated  Plug. 

The  prototype  utilized  a smaller,  less  expensive  bag  seal,  check  valves  in  the  mandrel  and  was  stream- 
lined to  facilitate  diver  handling.  In-water  testing  verified  bag  seal  design  and  provided  sufficient 
information  to  verify  check  valve  utilization. 


RETRIEVAL  TECHNIQUE  DEVELOPMENT 

Retrieval  techniques  have  evolved  in  parallel  with  equipment  and  flight  hardware  configuration 
changes.  Additional  changes  have  been  initiated  to  improve  personnel  safety. 

Prior  to  STS-1 

Prior  to  STS-1,  extreme  emphasis  was  placed  upon  crane  operations  training.  This  was  mandated 
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by  the  requirement  to  develop  safe  procedures  for  deploying  the  nozzle  plug  and  to  develop  operator 
techniques  which  would  preclude  damage  to  the  frustum  during  retrieval  operations. 

At  this  time,  it  became  evident  that  a diving  contigency  would  be  desirable.  To  this  end,  a 
basic  five-man  dive  team  was  formed,  trained  and  with  the  advent  of  the  BARB,  developed  preliminary 
insertion  techniques. 


Prior  to  STS-2 


NASA's  decision  to  suspend  NP  operations  on  STS-2  placed  heavy  emphasis  on  additional  diver 
training  and  BARB  techniques  had  to  be  fully  operational.  STS-1  operations  demonstrated  that  the  SRB 
would  return  to  the  spar  mode  in  various  sea  states.  To  eliminate  this  potential  hazard  in  shallow 
waters,  an  astern  air  supply  technique  was  developed  and  utilized.  Upon  initi  1 rotation  to  the 
semi -log  mode,  the  SRB  air  hose  was  disconnected  and  capped  200  feet  aft  of  the  BARB.  Additionally, 
a 100  foot  positively  buoyant  polypropylene  line  was  attached  to  the  free  end.  This  allowed  a re- 
trieval vessel  to  work  astern  of  the  distressed  SRB,  retrieve  the  airline  and  resupply  air  without 
interrupting  the  tow  of  either  vessel. 


Prior  to  STS-3 


Towing  procedures  had  proven  to  be  a continuous  problem.  Elimination  of  these  problems  was 
analyzed  with  subsequent  equipment  change.  The  final  design  concept  H-Bitt  and  capstan  towing  equip- 
ment was  removed  allowing  the  towline  to  be  deployed  directly  from  the  towing  winch.  This  change 
required  two  seamen  versus  five  for  handling  the  towline  and  eliminated  towline  chafing  problems. 

It  also  allowed  for  easy  variance  in  towline  lengths  as  dictated  by  changing  sea  states. 

Prior  to  STS-4 


Decelerator  subsystem  problems  necessitated  removal  of  the  parachute  flotation  which,  in  turn, 
mandated  that  parachutes  remain  attached  to  the  SRB.  Various  parachute  removal  techniques  were 
investigated  and  detachment  at  the  40  foot  release  links  was  elected  as  the  preferred  mode. 

Parachute  removal  utilizing  this  mode  requires  the  attachment  of  two  180  pound  positive  floats 
to  each  leg  of  the  parachute.  This  is  accomplished  by  divers  passing  a nylon  line  through  the  center 
of  four  dispersion  bridles  above  the  40  foot  release  links.  The  line  is  attached  to  the  floats  effec- 
tively transferring  the  parachute  weight  from  the  SRB  to  the  floats  allowing  the  divers  to  disassem- 
ble the  release  links.  Once  released  the  parachute  floats  free  and  vessel  retrieval  can  commence. 

When  parachutes  are  detached  in  this  mode,  the  apex  is  approximately  200  feet  beneath  the  ocean 
surface.  Parachutes  can  be  retrieved  in  three  basic  modes,  i.e.,  apex  first,  one  leg  or  two  leg. 
Retrieval  and  refurbishment  operations  prefer  the  apex  first  recovery,  sea  conditions  permitting. 

This  is  accomplished  by  towing  the  parachute,  with  one  leg,  into  the  current  until  the  apex  is  float- 
ing 15  to  25  feet  below  the  surface.  Divers  from  a following  boat  enter  the  water  and  attach  a nylon 
messenger  line  through  the  apex  suspension  lines.  This  messenger  is  passed  to  the  retrieval  vessel 
and  the  parachute  is  reeled  onboard. 


Prior  to  STS-5 


Extensive  testing  of  the  prototype  At-Sea  Plug  was  conducted  in  a water  environment.  Divers 
established  handling  and  docking  techniques  which  impacted  design  criteria. 


PLANNED  FUTURE  DEVELOPMENTS 

At-Sea  D0P  development  has  continued  on  schedule  with  the  first  devices  to  be  operational  for 
STS-7.  The  device  will  be  inserted  manually  at  depth,  permit  SRB  dewatering  to  the  full  log  mode, 
thereby  improving  towing  characteristics  and  subsequently  reducing  corrosive  in-water  time. 

The  DOP's  primary  structure  element  is  constructed  from  12'  of  10"  diameter  aluminum  pipe.  It 
contains  a one-way  valve  and  has  an  "0"-ring  seal  and  end  cap  at  each  end.  The  forward  half  of  the 
pipe  houses  an  8"  diameter  dewatering  hose.  A sliding  collar  is  fitted  outside  the  forward  end  of 
the  pipe  which  moves  three  folding  arms  into  open  or  closed  positions.  A 1/2"  ball  valve  penetrates 
this  pipe  forward  of  the  one-way  valve  and  is  used  to  add  ballast  water  on  the  surface,  and  equalize 
the  pipe  after  the  DOP  is  locked  into  place  at  depth  allowing  the  two  end  caps  to  fall  free. 

A 52"  diameter  mandrel  is  flanged  around  this  pipe  with  an  inflatable  neoprime  bag  seal  bolted 
around  the  rim.  Three  hinge  points  are  welded  to  the  top  outer  edges  of  the  mandrel  as  supports  for 
the  three  folding  arms.  The  bag  air  supply  and  valve  are  attached  to  the  lowerside  of  the  mandrel. 
Three  attachment  points  are  welded  to  the  bottom  of  the  mandrel  supporting  three  rigid  legs  that  are 
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welded  to  the  after  10"  pipe  section. 

The  DOP  utilizes  a chain  and  cable  system  for  opening  and  restraining  the  locking  arms  during  in- 
sertion. A rod,  chain  and  ratchet  system  closes  and  locks  the  arms  after  docking. 

A 1 1/2"  pipe  with  a quick-disconnect  and  check  valve  passes  through  the  mandrel  and  is  attached 
to  each  end  of  the  10"  pipe  providing  a means  for  pressurizing  the  SRB. 

Plans  are  currently  being  formulated  to  establish  procedures,  equipment  and  time  lines  required 
to  support  retrieval  operations  in  the  Pacific  area. 

This  author  believes  labor  intensified  diving  requirements  and  increased  launch  rates  will 
require  a review  of  the  original  baselines;  i.e.,  remote-controlled  dewatering  devices  and  detached 
parachute  with  subsequent  reduction  of  diver  requirements. 


TABLE  I.-  RETRIEVED  FLIGHT  HARDWARE  - REPLACEMENT  COSTS* 


MISSION 

S 

3B 

MAIN  PARACHUTES 

FRUS' 

ruM 

STS 

RIGHT 

LEFT 

1 

2 

3 

A 

5 

6 

RIGHT 

LEFT 

RIGHT 

LEFT 

1 

25M 

25M 

65K 

65K 

65K 

65K 

— 

— 

50K 

50K 

1.5H 

1.5M 

53.36M 

2 

25M 

25M 

65K 

65K 

65K 

65K 

65K 

— 

50K 

50K 

1.5M 

1.5M 

53.425M 

3 

25M 

25M 

65K 

65K 

65K 

65K 

65K 



50K 

50K 

1.5M 

1.5M 

53.425M 

4 

50K 

50K 

1.5M 

1.5M 

3.  in 

5 

25M 

25M 

65K 

65K 

65K 

65K 

65K 

65K 

50K 

50K 

1.5M 

1.5M 

53.49M 

TOTALS 

100M 

100M 

260K 

260K 

260K 

260K 

195K 

65K 

250K 

250K 

7.5M 

7.5M 

216. 8M 

* COST  DATA  PROVIDED  BY  MSFC,  APRIL  1983 
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SPACE  SHUTTLE 
FLIGHT  READINESS  FIRING 
DRESS  REHEARSAL  FOR  STS-1 


Lt  Colonel  Warren  L.  Riles 
HQ  Space  Division/YOO 
Los  Angeles  AFS,  CA 


ABSTRACT 


As  we  approached  the  first  space  Shuttle  launch,  the  tension  and  excitement  increased  with  each 
passing  day.  The  dedication  and  resolve  of  the  joint  government/contractor  team  was  also  increasing 
as  we  approached  the  Flight  Readiness  Firing  (FRF)  test.  The  FRF  test  afforded  us  an  opportunity  to 
assess  the  readiness  or  the  integrated  systems  to  support  the  STS-1  launch  and  flight.  The  assessment 
included  the  following  integrated  systems:  Structures  and  mechanics;  thermal  design  integration;  pro- 

pulsion and  power;  avionics  and  software;  guidance,  navigation,  and  control;  mechanical  systems;  com- 
munications and  tracking;  an  integrated  ground  systems. 

The  Space  Shuttle  Flight  Readiness  Firing  was  also  an  excellent  opportunity  to  exercise  the  oper- 
ational capability  developed  for  STS-1  at  a time  when  test  teams,  facilities,  plans  and  procedures 
were  in  a flight  ready  condition. 

To  ensure  that  we  were  prepared  to  function  effectively  as  an  integrated  team  for  STS-1,  we 
conducted  a simulation  of  the  pre-mission  activities,  countdown  and  launch  operations,  and  post- 
mission activities  associated  with  STS-1  in  conjunction  with  the  Space  Shuttle  Flight  Readiness  Fir- 
ing. The  exercise  involved  all  STS-1  management  and  operations  elements  functioning  as  they  would 
for  STS-1  launch  to  the  degree  that  was  practical  and  productive. 


The  final  step  in  the  Space  Shuttle  system  verification  network  prior  to  the  first  DDT&E  flight 
was  a static  firing  of  the  Space  Shuttle  main  engines  using  mated  flight  vehicle  elements  in  as  near 
as  possible  flight  configuration,  on  launch  pad  39A  at  KSC.  The  flight  readiness  firing  (FRF)  was 
conducted  as  part  of  the  countdown  demonstration  test  (CCDT)  for  the  first  Shuttle  manned  flight. 

In  previous  space  and  missile  programs,  static  firing  and  integrated  flight  control  and  propul- 
sion tests  were  conducted  at  a test  site  prior  to  the  vehicles  arriving  at  the  launch  sites.  However, 
due  to  the  unique  design  and  multi -elements  of  the  Shuttle,  all  flight  systems  (propulsion,  flight 
control  and  avionics)  were  not  integrated  until  mated  at  the  launch  site.  Although  each  element  and 
subsystem  of  the  Shuttle  goes  through  development  and  verification  test,  including  a main  propulsion 
system  test  (MPT)  utilizing  a flight  ET  or  Orbiter  aft  fuselage  with  SSMEs,  the  total  integrated  sys- 
tem was  not  available  until  the  vehicle  was  mated  at  the  launch  pad.  Two  other  important  factors 
necessitated  a flight  readiness  firing:  (1)  the  Shuttle  program  had  no  unmanned  flights  scheduled 

and  (2)  no  facility  checkout  vehicle.  Specific  system  objectives  realized  from  the  FRF  were: 

a.  First  verification  of  the  flight  MPS  and  associate  subsystem  structural  integrity  and 
performance  during  SSME  firing  (exact  launch  conditions  up  to  SRB  ignition). 

b.  First  verification  of  the  adequacy  of  flame  and  heat  protective  shielding  for  SRBs  and  ET 
during  SSME  pre-liftoff  firing  and  simulated  launch  abort  shutdown. 

c.  First  integrated  avionics/MPS  test  (SSME  control  and  monitoring  with  Orbiter  avionics). 

d.  First  integrated  APU/hydraulics/SSME/f light  control  functional  test. 

e.  Additional  verification  of  prelaunch  servicing  procedures  and  countdown  timelines. 

f.  Additional  SSME  cluster  firing  data  to  verify  first  flight  vehicle  MPS  predicted  performance. 

The  FRF  was  conducted  with  an  unmanned  Orbiter.  Additional  switch  control  functions  had  been 
provided  in  the  Orbiter  for  ground  control  through  the  launch  processing  system  (LPS)  that  would  not 
have  been  required  for  a manned  FRF.  These  additional  ground  control  functions,  plus  a modified 
flight  software  program,  allows  the  Shuttle  main  propulsion  system  (MPS)  to  be  tested  at  the  launch 
pad  with  the  vehicle  configured  for  flight.  The  solid  rocket  boosters  (SRB)  flight  control  systems 
were  not  activated  for  the  FRF;  however,  SRB  ignition  commands  and  SRB  holddown  release  signals  were 
verified.  The  Orbiter  T-0  umbilicals  and  the  external  tank  liftoff  umbilicals  remained  connected  dur- 
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ing  the  2- second  firing  of  the  MPS.  The  Orb  iter  Orbital  maneuvering  systems  (OMS)  and  the  forward 
and  aft  reaction  control  systems  (RCS)  were  not  activated  during  the  FRF.  Orbiter  flight  control  com- 
mands were  exercised  during  the  20-second  firing.  At  the  termination  of  the  20-second  firing,  the 
three  SSME's  were  sequentially  shut  down  simulating  a prelaunch  shutdown.  Following  the  post  firing 
securing,  a vehicle  inspection  and  data  analysis  were  conducted  and  the  vehicle  was  reconfigured  and 
prepared  for  the  first  STS  launch. 


REQUIREMENTS 


Test  Philosophy 

Wet  CDDT/FRF  was  a detailed  practice  run  for  the  STS-1  launch  and,  as  such,  identified  any  fail- 
ure or  weaknesses  in  any  systems  or  operating  conditions  not  occurring  during  pretesting.  All  condi- 
tions were  identical  to  or  as  close  to  the  actual  STS-1  timelines  and  launch  preparation  as  possible. 

This  was  a one-time-only  test  on  Orbiter  vehicle  102  and  was  preceded  by  a tanking  and  detanking 
checkout  of  the  Orbiter,  external  tank,  and  ground  systems/facilities.  The  FRF-unique  and  piggyback 
software  tests  at  the  Shuttle  Avionics  Integration  Laboratory  at  Johnson  Space  Center  (JSC)  were 
completed  and  instrumentation  for  special  test  installed,  characterized,  and  calibrated.  All  facil- 
ity and  servicing  equipment  was  operationally  ready  to  support  FRF  countdown.  The  Space  Shuttle  main 
engines  (SSME)  hardware  backup  shutdown  capability  checkout  was  completed.  The  crew  cabin  was  not 
manned  once  propellant  loading  started  and  those  Shuttle  subsystems  that  required  operational  control 
after  that  time  was  configured  for  and  had  ground  remote  control  capability.  The  T-0  umbilical 
interfaces  were  maintained  through  the  FRF  along  with  general  purpose  computer/launch  processing  sys- 
tem (GPC/LPS)  polling  command  capability. 

The  FRF  firing  duration  was  limited  to  approximately  20  seconds  of  main  stage  operation.  SSME 
start  was  identical  to  STS-1  launch:  The  engines  were  tested  at  94  percent  and  100  percent  rated 

power  level  (RPL)  with  shutdown  occurring  from  100  percent  RPL  (launch  abort).  SSME  gimbaling  was 
performed  at  both  power  levels.  See  Figure  1 and  2 for  FRF  thrust  profile  and  FRF  gimbaling  profile. 
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Figure  2.-  FRF  glmballng  profile. 


The  flight  and  ground  software  were  structured  to  maintain  the  launch  processing  system  (LPS) 
contact  with  the  vehicle  throughout  the  test  and  preclude  the  flight  software  from  progressing  to 
major  mode  102  (ascent).  Redundant  set  launch  sequence  (RSLS)  flight  software  operated  in  major  mode 
101  (prelaunch)  and  controlled  the  functions  of  the  Orbiter  systems  and  issued  commands  to  the  rest 
of  the  Shuttle  vehicle  from  T-35  seconds  until  approximately  T+26  seconds  for  FRF.  The  time  from  T-20 
minutes  to  T-0,  was  identical  to  STS-1  countdown.  The  time  from  T-0  to  approximately  T+26  was  FRF 
test  software  control.  This  test  verified  that  the  Shuttle  vehicle  was  ready  for  launch. 

The  various  phases  of  the  wet  CDDT/FRF  were: 

o Pre-FRF  started  with  power  up  for  the  CDDT/FRF  simulated  run  just  prior  to  the  actual  test 
o Wet  CDDT/FRF  began  with  the  launch  countdown  type  of  action  starting  at  T-53  hours  with  call 
to  station  from  0MI  S0014  and  verification  of  configuration  of  all  elements  ready  for  the  test 
o FRF  ended  with  the  last  cryogenic  liquid  out  of  the  vehicle,  which  was  the  beginning  of 
post-FRF  activities 

o Post-FRF  ended  with  the  completion  of  all  FRF-unique  objectives,  closeout  of  the  test 
discrepancies  affecting  configuration,  and  the  0MRSD  requirements  being  met 


1 

TEST  OBJECTIVES 


FRF  provided  the  only  opportunity  to  subject  the  Space  Transportation  System  (STS)  to  the  launch 
environment  without  concern  for  ascent  transition.  The  test  provided  confidence  that  the  STS  was 
fully  integrated  in  the  critical  functions  where  elements  have  not  been  tested  together  in  the  launch 
environment.  The  primary  test  objectives  to  be  accomplished  during  this  test  were: 

o Exercise  all  elements  of  the  STS,  including  personnel,  facilities,  vehicle,  and  software  in 
a real-time  launch  countdown  culminating  in  a SSME  firing  and  simulated  launch  to  ensure  proper  inte- 
gration prior  to  STS-1  flight 

o Verify  the  capability  of  the  launch  facility  to  provide  propellants  to  the  Shuttle  at 
specified  conditions  (i.e.,  subjecting  the  external  tank  (ET)  and  Orbiter  elements  to  the  same  thermal 
environment  as  STS-1  and  to  maintain  pressure  in  the  ET  from  the  ET/SSME  and  main  propulsion  system 
(MPS)  control  during  SSME  firing) 

o Verify  the  functional  performance  of  the  integrated  auxiliary  power  uni t(APU) /hydraulic/flight 
control  system  during  simultaneous  engine  gimbaling  and  throttling 

o Load  and  operate  the  power  reactant  supply  and  distribution  (PRSD)  system  in  the  Orbiter  with 
cryogenic  reactants  for  the  first  time 

o Verify  the  predicted  performance  of  the  ET-SSME-MPS  interfaces  and  systems,  including  soft- 
ware and  the  capability  of  the  avionics  equipment  to  effectively  monitor  and  control  the  active  vehi- 
cle under  dynamic  prelift-off  vibroacoustic  conditions 

o Verify  that  LPS/GPC  control  of  launch  countdown  sequencing  can  be  performed  down  to  T-0  along 
with  simulated  launch  abort  shutdown  and  securing  in  post  T-0  time 

o Verify  compatibility  of  the  Shuttle  avionics  equipment  with  the  launch  radio  frequency  envi- 
ronment 

o Provide  data  to  verify  the  validity  of  modeling  techniques  to  extend  dynamic  and  vibroacoustic 
analysis  from  previous  test  to  KSC  conditions 

o Assess  the  "twang"  effects  of  the  SSME:  in  the  start  position  at  ignition,  and  on  the  STS 

flight  vehicle  without  SRM  ignition 

o Exercise  the  data  acquisition  system,  data  reduction  methods,  and  data  analysis  documentation 
methods  to  be  used  for  launch 
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TEST  DESCRIPTION 


ORIGINAL  PAGE 
OF  POOR  QUALITY 


SEQUENCING 

The  sequence  of  operations  between  T-52  hours  and  T+160  hours  are  summarized  in  Figures  3 and  4. 
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Figure  3.-  CDDT/FRF  timeline  flow. 
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Figure  4.-  FRF  loading  timeline. 
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THE  CHALLENGES 


ORB  ITER  SSME  WATER  DELUGE  SYSTEM 


DESCRIPTION 


SSME  post-shutdown  after-burning  had  occurred  on  several  occasions  on  the  MPTA  at  NSTL.  Program 
concern  was  expressed  that  a similar  condition  would  occur  during  FRF  or  during  a pad  abort. 

A study  was  made  by  the  integration  contractor  to  determine  thermal  effects  on  the  most  sensi- 
tive vehicle  hardware  (engine  mounted  heatshield)  and  to  evaluate  and  recommend  an  effective  means  of 
protecting  the  vehicle  against  the  potential  from  an  engine  shutdown/abort  as  mentioned  above. 

A facility  system  with  a series  of  water  spray  nozzles  mounted  around  the  periphery  of  the  MLP 
opening  and  directed  to  impact  discrete  areas  of  the  Orbiter  aft  heatshield  structure  was  recommended 
and  approved  by  the  Level  II  PRCB.  As  designed,  the  system  is  tied  to  the  MLP  fire  system  to  be 
activated  manually  from  the  LCC  after  detection  of  a potentially  damaging  afterburning  condition. 


POTENTIAL  PROBLEMS 


1.  Damage  to  TPS.  - Potential  damage  to  TPS  by  direct  impact  of  the  water  spray  was  a primary 
concern  of  the  proposed  system.  To  answer  this  question  a special  water  spray  impact  test  was 
carried  out  at  the  integration  contractor's  laboratory  and  test  facility  in  Downey,  CA.  Results  of 
the  test  demonstrated  that  TPS  would  not  be  damaged  with  the  planned  application  of  the  nozzles. 

Also,  characteristics  of  the  nozzle  spray  plume  (throw  distance  and  diameter  vs.  pressure)  were  deter- 
mined to  verify  proper  nozzle  select ion /application . 

2.  Dedicated  Spray  System  - The  requirement  of  a fully  independent  water  supply  for  the 
Orbiter-SSME  deluge  system  could  not  be  met  on  STS-1.  This  was  due  to  the  fact  that  the  existing  6" 
diameter  supply  line  is  flow  limited  and  can  serve  only  one  of  the  three  major  Orbiter  protective 
spray  systems  at  any  given  time. 

For  STS-3  this  condition  will  be  eliminated  by  the  replacement  of  the  6"  supply  line  with  a 12"  line, 
permitting  full  flow  to  all  of  the  protective  systems  simultaneously,  if  necessary.  Incorporation  of 
the  12"  supply  on  MLP-1  for  STS-1  was  delayed  until  STS-3  due  to  the  high  potential  for  impacting  FRF 
and  the  STS-1  launch  schedule  with  the  significant  construction  effort  required  on  the  MLP. 

3.  Automatic  vs.  Manual  Spray  Actuation  - Initial  system  requirements  specified  that  the 
Orbiter-SSM£  deluge  system  be  initiated  by  automatic  control  in  the  event  of  a planned  or  aborted 
SSME  shutdown  to  minimize  the  reaction  time  for  flow  of  the  protective  spray. 

Due  to  potential  vehicle  launch  schedule  impact  in  the  event  that  water  sprays  were  activated 
needlessly  (without  significant  afterburning)  following  engine  shutdown,  direction  was  given  by  the 
PRCB  that  the  system  would  be  manually  activated.  As  planned,  control  of  the  system  will  be  under 
the  cognizance  of  an  operator  in  the  LCC  augmented  by  UV  sensors  viewing  the  SSME  nozzles  and  observa- 
tion of  the  vehicle  through  closed  circuit  TV. 

4.  Alignment  Verification  of  Spray  Nozzles  - During  the  nozzle  alignment  procedure  prior  to  FRF 
it  was  determined  that  four  of  the  spray  nozzles  on  the  north  side  of  the  MLP  would  impact  directly 
on  the  trailing  edge  of  the  Orbiter  body  flap.  To  avoid  the  potential  of  TPS  damage  those  nozzles 
were  changed  to  fog  jet  nozzles  which  produce  a "softer"  spray  with  less  impact  energy  at  the  tile 
surface. 

5.  Water  Contamination  of  QMS  Nozzles  - The  use  of  fly-away-throat  plugs  for  the  OMS  engines 
was  deemed  unacceptable  to  the  Program  and  will  not  be  used  on  STS-1  and  subs.  To  minimize  the  possi- 
bility of  direct  spray  entering  the  OMS  engines,  two  water  nozzles  were  re-aimed.  This  request  was 
initiated  through  a formal  Engineering  Service  Request  (ESR)  as  a manadatory  requirement  prior  to 
STS-1  and  has  been  accomplished. 

6.  Water  Flow  Test  - A full  deluge  test  with  the  vehicle  in  place  was  deemed  not  feasible  due 
to  potential  schedule/cost  impact  to  FRF/STS-1.  In  lieu  of  this  final  vertifi cation  test  the  follow- 
ing procedures  were  approved  by  the  Program  as  an  acceptable  means  of  determining  adequacy  of  the  sys- 
tem: 

a.  Analysis  of  A&E  calculations  for  f low-pressure. 
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b.  Alignment  of  water  spray  nozzles  using  a light  source  to  assure  that  spray  impact  areas 
were  in  accordance  with  the  design  drawings. 


Results 


All  of  the  potential  problems  associated  with  Orbiter-SSME  deluge  system  have  been  resolved  as 
noted.  Completion  of  the  ESR  for  re-aiming  at  water  nozzles  has  been  implemented  for  STS-1. 


HYDROGEN  BURN-OFF  SYSTEM 


Description 

A detailed  assessment  of  main  engines  ignition  overpressure  data  from  MPTA  Static  Firings  in 
early  1980  revealed  the  necessity  of  a hydrogen  burn-off  system  at  the  launch  pad  to  avoid  poten- 
tially damaging  overpressures  caused  by  ignition  of  the  SSME  fuel  lead  of  hydrogen  gas  at  engine 
start. 

Due  to  the  limited  time  available  prior  to  STS-1,  a NASA/Contractor  working  group  was 
established  to  expedite  the  design,  development,  delivery,  and  verification  of  the  burn-off  system. 

After  evaluation  of  alternate  methods  including  an  engine  mounted  fly-away  system,  a pyrotechnic 
initiated,  facility  ground  system  was  baselined  by  the  PRCB.  This  concept  utilized  an  "off-the-shelf" 
igniter  to  minimize  delivery  time  and  provide  greater  assurance  of  supporting  STS-1  with  a function- 
ally qualified  system. 

In  addition,  the  development  of  a second  pyrotechnic  device  (the  long  throw  igniter)  was 
approved  as  a backup  to  the  baselined  unit.  In  concept,  this  unit  offered  distinct  advantages  over 
the  baselined  short  throw  igniter. 

a.  It  could  be  mounted  on  the  tail  service  masts  thus  eliminating  the  need  for  cumbersome 
pylons  required  to  support  the  short  throw  igniters. 

b.  Avoided  interference/operational  contraints  with  engine  access  platforms. 

c.  Eliminated  handling  and  maintenance  of  pylons. 

d.  Enhanced  safety. 

e.  It  delivered  a high  density  pattern  of  ignition  particles  under  the  entire  area  of  the 
SSME  nozzle. 

The  major  disadvantage  of  this  device  was  the  limited  time  available  to  accomplish  the  full 
development  and  qualification  program  that  would  be  required  prior  to  STS-1. 

An  integrated  Verification  Plan  was  formulated  for  the  candidate  pyro  devices  which  included 
the  orderly  progression  from  single  engine  testing  at  SSFL  leading  to  cluster  engine  testing  on 
the  MPTA  at  NSTL. 


Problems 


The  subsequent  implementation  of  this  plan,  and  the  problems  encountered,  resulted  in  the  timely 
evolution  of  the  preferred  long  throw  igniter: 

a.  Analyses  in  support  of  testing  revealed  that  the  short  throw  igniter  could  be  adversely 
affected  by  wind.  Conversely,  the  long-throw  igniter  was  relatively  insensitive  to  the  wind.  (This 
was  later  confirmed  by  wind  tests  conducted  at  the  vendor's  facilities). 

b.  On  Static  Firing  12,  data  acquired  on  the  first  usage  of  the  long  throw  igniters  revealed 
high  overpressure  levels  associated  with  engine  E-l.  The  baseline  design  provided  igniters  for  E-3 
and  E-2  only,  for  both  MPTA  at  NSTL  and  0V-102  at  KSC.  This  was  due  to  difficulties  involved  in 
mounting  short  throw  igniters  near  Engine  1 and  the  belief  that  E-l  hydrogen  would  be  ignited  by  E- 
3 and  E-2  burning.  MPT  SF12  demonstrated  the  necessity  of  igniters  on  all  three  engines. 
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FRF" INGESTION  IN  THE  AFT  FUSALAGE 


Figure  5.-  FRF--H2  Ingestion  In  the  aft  fuselage. 
Results 


Inherent  throw  capability  of  the  long  throw  igniter  and  simplicity  of  the  mechanical  installa- 
tion on  the  TSMs  made  it  feasible  to  add  the  additional  igniters  for  Engine  1 at  KSC.  This  was  accom- 
plished with  no  impact  to  the  FRF  schedule. 

Review  of  FRF  data  has  indicated  an  effective  burn-off  system  that  limited  the  SSME  overpressure 
to  less  than  0.1  PSID.  The  Hydrogen  Burn-Off  System  was  now  qualified  to  support  STS-1. 


FLIGHT  READINESS  FIRING  (S0014) 

Overall  Objective 

Provide  final  verification  of  critical  integrated  systems  (i.e.,  main  propulsion  system,  etc.). 
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Dry  CDDT  Objectives 


a.  Interface  the  flight  crew  and  launch  test  team  in  a count  rehearsal. 

b.  Demonstrate  the  sequence  of  operations  required  to  prepare  Shuttle  for  launch. 

c.  Evaluate  timelines  established  for  launch  countdown. 


Problems 

The  FRF  countdown  went  very  smoothly.  There  were  a total  of  151  Interim  Problem  Reports 
(IPRs)  written  against  the  test  of  which  13  affected  the  ground  equipment.  Of  the  13  IPRs  the 
following  five  were  considered  to  be  significant: 

PRSD  Sampling  Results  (IPR-017).  During  the  ground  servicing  of  the  PRSD  system,  samples 
of  the  reactant  gases  failed  to  pass  the  sample  test.  The  Ho  contained  a high  percentage  of  GHe 
and  the  Op  contained  a high  percentage  of  GNp.  It  has  been  determined  that  this  was  caused  by 
a ground  procedure  problem  during  the  pulse  purging  of  the  ground  system.  This  problem  was  corrected 
prior  to  STS-1  launch. 

Mater  Leaking  at  OAA/Orbiter  Interface  (IPR-038).  During  the  FRF  countdown,  rain  water  was 
leaking  past  the  dock  seal  of  the  OAA  white  room  at  the  Orb iter  moldline  when  the  RSS  was  retracted. 
Prior  to  this  time,  the  item  of  GSE  which  prevents  water  from  entering  the  crew  hatch  was  not 
installed.  The  GSE  model  A70-0643-3  is  a Fiberglass  scupper  that  fits  over  the  crew  hatch  to  direct 
water  away  from  the  hatch.  Without  this  GSE  installed,  water  was  allowed  to  enter  the  crew  module. 

A significant  amount  of  water  had  to  be  removed  after  FRF. 

This  problem  was  resolved  prior  to  launch  in  that  the  GSE  (A70-0643-3)  was  installed  around  the 
crew  hatch. 

GOX  Vent  Hood.  During  the  tanking  test  prior  to  FRF  it  was  noted  that  GOX  vapors  were  leaking 
from  the  GOX  vent  hood  during  loading  of  the  ET  LOX  tank.  It  was  determined  that  the  leakage  was 
past  the  seal  where  the  seal  interfaces  with  the  ET  tank  SOFI.  This  GOX  leakage  past  the  seal  caused 
erosion  of  the  SOFI  on  the  ET. 

Pressure  was  increased  on  the  seal  for  FRF  but  the  seal  ruptured  on  the  South  side  of  the  ET 
tank  just  below  the  louvers.  The  tank  was  approximately  12-14  percent  full  and  it  was  decided  to  re- 
tract the  hood  at  that  time  and  proceed  with  the  LOX  loading.  The  seal  on  the  North  side  operated 
properly. 

Subsequent  to  FRF  a series  of  tests  were  run  at  LETF  to  evaluate  the  problem.  It  was  found  that 
replacing  the  orifice  configuration  from  a standard  orifice  to  a cruiciform  orifice  lowered  the  pres- 
sure on  the  louvers  and  evenly  distributed  the  pressure  on  the  louvers.  The  pressures  on  the  North 
and  South  seals  were  now  essentially  the  same. 

Subsequent  to  FRF  an  evaluation  of  the  location  of  the  GOX  vent  arm  indicated  that  the  seal  may 
have  been  slightly  out  of  position  and  on  one  corner  of  the  louvers  rather  than  on  the  SOFI.  This 
would  have  contributed  to  the  failure.  Steps  have  been  taken  to  accurately  position  the  seal  around 
the  louvers. 

On  March  9,  1981,  the  Level  II  PRCB  decided  to  install  the  cruciform  orifice  on  ET-1  based  on 

the  LETF  tests.  Starting  March  13,  1981,  a series  of  tests  were  conducted  on  the  LETF  with  an 

improved  seal  design  and  cruciform  orifice.  The  tests  were  successful. 

Hypergolic  Storage  Tank.  An  incident  occurred  prior  to  the  FRF  countdown  involving  the 
hypergolic  storage  tank  located  on  the  perimeter  road  around  the  pad.  During  hypergolic  servicing, 
the  heater  in  the  storage  tank  failed.  Servicing  continued,  resulting  in  a failure  of  the  storage 
tank.  A new  heater  has  been  installed  in  the  tank  and  a constraint  has  been  added  that  use  of 
the  tank  when  the  heater  is  off  is  prohibited. 

Pressure  Spike  LOX  Fill  and  Drain  System.  A pressure  spike  of  approximately  150  psig  occurred 

on  the  ground  side  of  the  LOX  fill  and  drain  line  during  detanking.  The  pressure  on  the  Orbiter 

side  of  the  interface  did  not  exceed  the  proofpressure  of  the  line.  Preliminary  indications  revealed 
that  this  problem  can  be  corrected  procedurally  by  refilling  the  ground  system  up  to  the  vehicle 
interface  prior  to  initiating  LOX  tank  drain.  This  was  not  implemented  until  STS-2. 
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Results 


In  summary,  the  ground  systems  performed  exceptionally  well.  All  test  objectives  were  met 
and  the  ground  systems  were  ready  to  support  launch. 


WET  CDDT/FRF  TEST  RESULTS 

The  Wet  CDDT/FRF  test  was  very  successful.  We  increased  our  knowledge  about  the  integrated  Shut- 
tle MPS  system.  All  the  SSMEs  will  leak  some  hydrogen.  The  SSME  joints  will  leak  hydrogen  and  oxy- 
gen below  specification  levels.  MPS  leak  tests  procedures  in  the  OPF  should  be  improved.  The  STS-1 
tests  procedures  were  for  joints  only  and  the  pressure  was  at  25  PSI.  The  leak  checks  procedures 
that  are  a part  of  the  SSME  second  E&M  at  NSTL  should  also  be  improved.  THE  MPS  FRF  objectives  were 
satisfied  and  Tables  I and  II  sumnarizes  the  problems  and  discrepancies  encountered  during  the  FRF 
test. 


TABLE  1 

SUMMARY  OF  MPS  FAILURES.  ANOMALIES.  DEVIATIONS.  AND  RECOMMENDED  ACTIONS 


SUBSYSTEM/ COMPONENT 

PROBLEM  DESCRIPTION 

PROBLEM 

CLASSIFICATION 

RECOMMENDED  ACTION 

go2  PRESSURIZATION 
• FCV-1 

LOW  GO 2 PRESSURANT  FLOW  FROM 
FCV-1  DOWNSTREAM  OF  ORB  ITER /SSME 
INTERFACE  WHEN  FCV  CYCLED  OPEN 

ANOMALY 

FLY  STS-1  AS  IS 

• FAILURE  INVESTIGATION 
DID  NOT  DISCLOSE 
SOURCE  OF  RESTRICTED  FLOW 

• ANALYSES  INDICATE  2 VALVE 
FAILURES  IN  FLIGHT  ACCEPTABLE 

HAZARDOUS  GAS 
DETECTION 

H2  AND  02  CONCENTRATIONS  APPEAR 

HIGHER  THAN  EXPECTED  DURING 
ENGINE  FIRING 

ANOMALY 

DETERMINE  EXPECTED  TRANSIENT 
CONCENTRATION  LEVELS  FOR  FRF 

• COMPARE  WITH  KSC  FRF  LEVELS 

EVALUATE  KSC  POST  FRF  LEAKAGE 
TEST  RESULTS 

ASSESS  LEVELS  DURING  SPECIAL 
TANKING  TESTS 

INITIATE  CORRECTIVE  ACTION 
IF  REQUIRED 

EXTERNAL  TANK 
• lh2  TANK 

ABILITY  TO  MAINTAIN  FLIGHT 
MASS  IN  LH2  TANK  MARGINAL 

• ATTRIBUTED  TO  FLOW 
RESTRICTION  DUE  TO 
WATER  ENTERING  VENT 
MANIFOLD  AT  BURN  POND 

ANOMALY 

RESOLVE  FACILITY  PROBLEM  AT  KSC; 
EVALUATE  FIXES  ON  SPECIAL  TANKING  TESTS 

• KSC  MODIFICATION  COMPLETED  BY 
TANKING  TEST 

• TANKING  TEST  RESULTS  WILL 
BE  EVALUATED 

lo2  PROPELLANT 
FEED  SYSTEM 

• L02  PREVALVE-1 

CLOSING  TIME  MARGINALLY  FAST 
COMPARED  TO  COMPONENT 
SPECIFICATION 

ANOMALY 

FLY  STS-1  AS  IS 

• SSME  ASSESSMENT  INDICATES 
TIMING  ACCEPTABLE  FOR 
IN-FLIGHT  SHUTDOWN 

• CONTINUE  EVALUATION  OF  PRE- VALVE 
TIMING  ON  SPECIAL  TANKING  TESTS 

SSME 

ME-1  AND  3 MR  APPEARS  HIGH 
BY  0.02  UNITS 

DEVIATION 

PROVIDE  UPDATED  MR  TAGS  FOR  STS-1 
PERFORMANCE  ASSESSMENT 

• ATTRIBUTED  TO  CONTROLLER 

PROPULSION  PERFORMANCE  PANEL  (PPP) 
REVIEW  CONTROLLER  LOGIC  FOR  MR 
CONTROL  ON  STS-2 

G02  PRESSURANT  SUPPLY 

DEVIATION 

PROVIDE  UPDATED  GO?  PRESSURANT  SUPPLY 

TEMPERATURE  NOT  AS  PREDICTED 

TAGS  FOR  STS-1  PERFORMANCE  ASSESSMENT 

• HIGHER  TEMPERATURES  ATTRIBUTED 
TO  MR  SHIFT 

PPP  ESTABLISH  METHOD  FOR  UPDATING  ENGINE 
TAGS  WHEN  HARDWARE  CONFIGURATION  CHANGES 

• LOWER  TEMPERATURE  ATTRIBUTED 
TO  HEAT  EXCHANGER  REORIFICE 

1 
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TABLE  2 


MPS  FRF  OBJECTIVE  AND  ACCOMPLISHMENT  SUMMARY 


OBJECTIVE 

OVERALL 

OR 

PRIMARY 

DEGREE  OF 
ACCOMPLISHMENT 

DISCREPANCIES /COMMENTS 

VERIFY  SATISFACTORY  INTEGRATION 
OF  ALL  SHUTTLE  FLIGHT  SYSTEMS  IN  A 
TYPICAL  TERMINAL  COUNTDOWN 
CULMINATING  IN  SSME  FIRING 

OVERALL 

FULLY  COMPLETED 

VERIFY  FUNCTIONAL  PERFORMANCE 
OF  THE  INTEGRATED  ET/SSME/APU/ 
HYDRAULIC/FLIGHT  CONTROL 
SYSTEMS  IN  THE  FLIGHT  CONFIGURATION 

OVERALL 

PARTIALLY 

COMPLETED 

• HAZ  GAS 
OPEN 

go2  FCV-1  APPARENT  RESTRICTED  FLOW 
JUST  AFTER  Tq 

• FAILURE  INVESTIGATION  DID  NOT 
DISCLOSE  PROBLEM 

• ACCEPTABLE  FOR  STS-1 

HIGHER  THAN  EXPECTED  H2  AND  02 

CONCENTRATIONS  IN  AFT  FUSELAGE  DURING 
ENGINE  FIRING 

• INITIAL  RESULTS  SHOW  CONCENTRATIONS 
BELOW  ALLOWABLE  LIMITS 

• EVALUATION  CONTINUING 

lo2  PREVALVE-3  CLOSING  TIME  MARGINALLY  FAST 

• COMPONENT  TIMING  ACCEPTABLE  FOR  SSME 
IN-FLIGHT  SHUTDOWN 

• ACCEPTABLE  FOR  STS-1 

ME-1  AND  3 MR  APPEARS  HIGH  BY  0.02  UNITS 

• ATTRIBUTED  TO  CONTROLLER 

• ACCEPTABLE  FOR  STS-1 

VERIFY  THE  CAPABILITY  OF  THE  LAUNCH 
FACILITY  TO  PROVIDE  PROPELLANTS  TO 
THE  SHUTTLE  VEHICLE  AT  SPECIFIED 
CONDITIONS 

PRIMARY 

FULLY  COMPLETED 

ABILITY  TO  MAINTAIN  LH?  FLIGHT  MASS  MARGINAL 

• ATTRIBUTED  TO  KSC  FACILITY  DRAIN  LINE 

• FLIGHT  MASS  ACHIEVED  FOR  FRF 

• ACCEPTABLE  FOR  STS-1 

VERIFY  PREDICTED  PERFORMANCE  OF 
THE  INTEGRATED  MPS  AND  INTERFACE 
COMPATIBILITY  WITH  ASSOCIATED 
FLIGHT  AND  GROUND  SYSTEMS 

PRIMARY 

FULLY  COMPLETED 

SSME  RECONSTRUCTED  TAGS  NOT  AS  PREDICTED 

• ME-1  AND  3 MR  0.02  UNITS  HIGHER 

• go2  pressurant  SUPPLY  TEMPERATURES 

DIFFERENT  BY  -100  TO  +60°  RANGE 

DEMONSTRATE  THE  HYDRAULIC 
WARRANT  FLOW  CAPABILITY 

PRIMARY 

FULLY  COMPLETED 

VERIFY  INTEGRATED  APU/ HYDRAULIC 
SYSTEM  OPERATION  DURING 
SIMULTANEOUS  SSME  GIMBALLING 
AND  THROTTLING 

PRIMARY 

FULLY  COMPLETED 

GUIDANCE,  NAVIGATION,  AND  CONTROL 


Integrated  Guidance  Navigation  and  Control  (IGN&C)  FRF  Test  Objectives 

The  prime  FRF  test  objectives  of  a total  GN&C  system  integration  nature  included:  (a)  demonstra- 
tion of  capatible  initialization  of  TVC  actuator  commands  for  hydraulics  application,  engine  start, 
run  and  shutdown  positions,  (b)  the  ability  to  perform  the  prelaunch  gimbal  slew  checks,  (c)  compati- 
bility of  the  Orbiter  avionics/software  with  the  SRB  thrust  vector  control  system,  (d)  confirmation 
that  the  dynamic  response  of  the  SSME  TVC  system,  in  the  "near  flight"  configuration,  was  comparable 
with  that  obtained  from  MPTA  test  results,  and  (e)  provision  of  a test  data  point  on  analytically 
predicting  elastic  body  response  to  a control  effector  command. 

IGN&C  Data  Assessment  - The  first  objective  was  accomplished  successfully,  although  the  yaw 
actuator  on  SSME  1 had  drifted  to  -1.04  degrees  (from  the  desired  value  of  zero  degrees)  prior  to 
Orbiter  APU  start.  This  was  expected  due  to  a non-zero  plumbing  torque  on  the  nozzle  at  zero  deflec- 
tion. The  second  objective  was  accomplished  with  no  anomalies;  i.e.,  the  slew  checks  were  performed 
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successfully  on  all  actuators,  even  though  the  SRB  HPUs  were  shut  down  prematurely  prior  to  comple- 
tion of  the  SRB  nozzle  slew.  There  was  adequate  kinetic  energy  in  the  turbine  to  permit  slew  comple- 
tion. Ability  of  the  Orbiter  to  properly  orient  the  SRB  nozzles  was  demonstrated  with  no  anomalies. 

This  FRF  test  provided  significant  and  substantial  information  relative  to  the  flight  readiness 
of  STS-1  in  areas  pertinent  to  the  general  technical  discipline  of  GN&C.  This  was  in  the  form  of  as- 
surances that:  (a)  the  prelaunch  procedure  successfully  prepared  avionics,  propulsion  and  hydraulic 

subsystems  for  launch,  (b)  the  LPS  was  properly  integrated  with  the  on-board  avionics,  and  (c)  in  the 
limited  scope  of  the  test,  the  individual  GN&C  elements  (consisting  of  sensors,  data  processing,  and 
control  effectors)  performed  their  required  functions. 


SRB  THRUST  VECTOR  CONTROL 


All  four  of  the  Auxiliary  Power  Units  (APU)  in  the  SRB  Hydraulic  Power  Units  (HPU)  were  shutdown 
prematurely.  The  scheduled  operation  of  the  APUs  was  to  be  activated  at  T-25  seconds  and  terminated 
at  T+22  seconds.  However,  at  T-19  seconds  (based  on  1 SPS  data)  the  system  A APU  of  the  left  hand 
SRB  exceeded  the  turbine  speed  LPS  redline  of  79,200  rpm  and  was  shutdown  properly  at  T-16  seconds 
(Figure  6) . 


Figure  6.-  Left  hand  SRB  system  A turbine  speed. 


The  redline  was  exceeded  because  of  a delay  in  receipt  of  the  hydraulic  by-pass  off  command  to 
system  B.  This  caused  the  A system  APU  controller  to  receive  a delayed  "hydraulic  pressure  OK"  sig- 
nal from  the  B system  HPU  which  caused  the  A system  APU  controller  to  command  the  A system  APU  to  op- 
erate at  110%  speed  longer  than  normal.  The  extended  110%  speed  operation  caused  the  APU  to  exceed 
the  79,200  rpm  redline.  Exceeding  the  redline  instituted  a shutdown  of  a A system  APU.  When  A sys- 
tem APU  shutdown,  A system  "hydraulic  pressure  OK"  signal  was  lost  by  the  B system  APU  controller. 
This  caused  the  B system  controller  to  command  B system  APU  to  operate  at  110%  speed  which  shutdown 
B system  APU  at  T-ll  seconds  because  of  exceeding  the  79,200  rpm  (Figure  7).  All  APU's  operated 
properly  as  commanded.  The  APU's  on  the  right  hand  SRB  also  shutdown  prematurely  due  to  similar 
causes  but  with  somewhat  different  times  of  occurrence.  System  A shutdown  at  T-13  seconds  and  system 
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B shutdown  at  T+2  seconds.  The  delay  in  shutting  down  system  B was  caused  by  having  to  unlock  the 
MDM  which  is  locked  out  at  T-10  seconds. 

The  turbine  speed  time  histories  for  all  four  APUs  are  shown  in  Figures  6,  7,  8,  and  9. 


MSID  B46R2408C  RAVE  APU  A TURBINE  SPEED  SENSOR  B 


Figure  7.-  Left  hand  SRB  system  B Figure  8.-  Right  hand  SRB  system  A 

turbine  speed.  turbine  speed. 

MSID  B46R2409C  RATE  APU  B TURBINE  SPEED  SENSOR  B 


Figure  9.-  Right  hand  SRB  system  B turbine  speed. 
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RESULTS 


Further  evaluation  of  the  HPU  shutdown  problem  has  verified  earlier  findings.  A proposal  has 
been  made  to  KSC  to  make  two  modifications  to  the  TVC  software  to  eliminate  the  possibility  of 
recurrence  of  the  problem. 

a.  Reduce  the  minimum  turbine  speed  redline  from  15  KRPM  to  10  KRPM. 

b.  Delay  the  initiation  of  the  79.2  KRPM  redline  by  approximately  2.0  seconds  minimum  from 
depressurization  valve  close  on  the  B system  of  the  right  hand  SRB. 

A diagram  of  the  proposed  redline  changes  is  shown  in  Figure  10. 


Figure  10.-  Proposed  APU  redline  changes. 


Figure  11.-  MPS  L02  fill  and  feed  system.  Figure  12.-  MPS  LO^  fill  and  feed  system. 
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SUMMARY 


The  Flight  Readiness  Firing  (FRF)  test  conducted  at  KSC  on  Launch  Pad  39A  on  February  20,  1981 
was  very  successful.  All  integrated  systems  FRF  objectives  were  satisfied  by  the  FRF  test  and  the 
follow-on  data  analyses.  The  significant  results  of  the  test  included  validation  of  the  launch  count- 
down sequencing,  including  critical  event  timing;  demonstration  of  flight  configured  MPS  functional 
and  performance  charcteristics;  math  model  validation  for  prediction  of  pre-launch  loads;  additional 
data  for  verification  of  pre-launch  vibroacoustic  and  thermal  environments. 
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DEFINITIONS 

1.  Space  Transportation  System  (STS):  An  integrated  system  consisting  of  the  Space  Shuttle 

(Orbiter,  External  Tank,  Solid  Rocket  Booster,  and  Flight  Kits),  Upper  Stages,  Payloads,  and  any 
associated  flight /ground  hardware  and  software. 

2.  Orbital  Fliqht  Test  (OFT):  One  of  four  (4)  scheduled  developmental  space  flights  of  the 

STS. 

3.  Fliqht:  That  portion  of  a mission  encompassing  the  period  from  launch  to  landing,  or  launch 

to  termination,  of  the  active  life  of  a spacecraft.  The  term  "Shuttle  Flight"  means  a single  Shuttle 
round  trip  (launch.  Orbital,  activity,  and  return).  One  flight  may  deliver  more  than  one  payload;  and 
more  than  one  flight  may  be  required  to  accomplish  one  mission. 

4.  Ground  Support  Equipment  (GSE):  Nonflight  equipment,  and  devices  required  for  the  handling, 

servicing,  inspection,  testing,  maintenance,  alignment,  adjustments,  checking,  repairing,  and 
overhauling  of  an  operational  end  item  or  subsystem  or  component  part  thereof.  This  may  include 
equipment  required  to  support  another  item  of  GSE  as  defined  herein. 

5.  Countdown  Demonstration  Test  (CDDT)  - Wet:  A full  dress  rehearsal  of  the  launch  countdown 

operations  including  cryogenic  propellant  loading  of  the  external  tank.  Test  normally  terminates  at 
time  for  Space  Shuttle  Main  Engine  (SSME)  ignition.  Flight  crew  does  not  participate  from  the  vehi- 
cle. 


6.  Countdown  Demonstration  Test  (CDDT)  - Dry:  A dress  rehearsal,  with  flight  crew  participa- 

tion, of  the  Launch  Countdown  operations  excluding  external  tank  propellant  loading  operations. 

7.  Fliqht  Readiness  Firing  (FRF):  A 20-second  firing  of  the  Space  Shuttle  Main  Engines  (SSMEs) 

in  a near  Shuttle  flight  configuration  on  the  launch  pad,  with  a scheduled  cutoff  prior  to  Solid 
Rocket  Booster  (SRB)  ignition  and  liftoff,  to  be  conducted  (one-time  only)  as  part  of  the  CDDT. 

8.  Cutoff : The  initiation  of  the  SSME  shutdown  sequence,  whether  generated  by  the  SSME  control- 

ler, GPC,  LPS  or  FEP  hardwire. 

9.  Automatic  Cutoff:  SSME  shutdown  resulting  from  an  out -of- tolerance  parameter  monitored  by 

either  the  SSME  controller,  GPC  or  LPS  for  cutoff  criteria. 

10.  Manual  Cutoff:  SSME  shutdown  initiated  by  console  operator.  LPS  is  backed  up  by  a 

hardwire.  The  hardwire  bypasses  the  common  data  buffer  and  inputs  directly  to  the  FEP. 


11. 

AADS 

Ascent  Air  Data  System 

12. 

DDT&E 

Design,  Development,  Test  and  Evaluation 

13. 

FASCOS 

Flight  Acceleration  Safety  Cutoff  System 

14. 

LETF 

Launch  Equipment  Test  Facility 

15. 

MPTA 

Main  Propulsion  Test  Article 
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16. 

NSTL 

National  Space  Technology  Laboratory 

17. 

OMI 

Operations  and  Maintenance  Instruction 

18. 

PRCB 

Program  Requirements  Change  Board 

19. 

PRSD 

Power  Reactant  Supply  and  Distribution 

20. 

PV&D 

Purge,  Vent,  and  Drain 

21. 

SPS 

Samples  per  Second 

22. 

SSFL 

Santa  Susana  Field  Laboratory 

23. 

TPS 

Thermal  Protection  System 
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ABSTRACT 


This  paper  is  written  to  provide  the  reader  with  an  understanding  of  the  tasks  and  effort  in- 
volved in  moving  the  Space  Shuttle  Development  Program  into  a truly  operational  and  reliable  Space 
Transportation  System.  Following  a description  of  what  we  believe  to  be  the  ten  major  characteris- 
tics of  an  operational  Shuttle,  we  will  describe  in  some  detail  the  changes  that  are  occurring  to  the 
three  major  elements  of  Shuttle  Processing,  On-Line  Operations,  Operations  Engineering,  and  Support 
Operations.  This  is  followed  by  a summary  of  the  twelve  major  tasks  or  goals  that  we  are  pursuing  in 
our  effort  to  create  a truly  cost  effective  and  efficient  system. 


INTRODUCTION 


America's  Space  Shuttle  has  proven  its  designed  capabilities  with  the  completion  of  final  phases 
of  development  and  test.  We  have  now  come  to  the  time  to  utilize  the  Shuttle's  unique  potential  by 
developing  improved  operations  geared  to  accomplishing  our  nation's  objectives  in  space.  The  goals 
of  Space  Shuttle  operations  are  reliability,  competitive  costs  and  mission  flexibility.  The  United 
States  government  and  industry  team  is  pursuing  these  goals  and  the  nation  and  the  world  will  see  a 
trend  of  increased  efficiency  and  decreased  cost  that  will  extend  well  into  the  next  decade. 


KEY  FEATURES  OF  SPACE  SHUTTLE  OPERATIONS 


To  understand  the  steps  that  have  been  necessary  to  transition  to  the  Space  Shuttle,  it  is  essen- 
tial to  define  the  characteristics  of  the  Shuttle  operational  era  and  the  major  functions  which  con- 
stitute ground  turnaround  and  support  operations. 


Shuttle  Operational  Era  Characteristics 


After  review  and  analysis  of  the  Shuttle  processing  flow,  the  Rockwell  Kennedy  Space  Center 
Launch  Operations  team  has  concluded  that  there  are  ten  major  operational  characteristics  that  must 
be  achieved  to  fully  realize  the  operational  goals  of  the  Space  Transportation  System  (STS).  These 
characteristics  are  totally  interrelated  and  can  only  be  achieved  in  consonance  by  a team  dedicated 
to  making  the  STS  a commercially  viable  program. 

1.  Repetitive  Operations 

2.  Systems  Maturity 

3.  Long  Range  Program  Planning 

4.  Flexibility 

5.  Performance  Margin 

6.  Operational  Improvements 

7.  Cost  Accountability 

8.  Launch-On-Time  Credibility 

9.  Reliability 

10.  Shift  in  Government  Management  Style 

One  characteristic  of  the  Shuttle  operational  era  is  repetitive  operations  performed  by  an  expe- 
rienced and  stable  work  force.  Many  of  the  operations  required  to  prepare  the  Shuttle  vehicle  for 
launch  and  to  refurbish  and  maintain  launch  site  facilities  require  a high  degree  of  skill  and 
craftsmanship,  but  are  basically  the  same  for  each  turnaround.  When  each  of  these  necessary  proces- 
ses, such  as  an  inspection  or  an  assembly  operation,  is  performed  by  the  same  individuals  or  crews 
in  the  same  way  every  time,  a consistent  quality  of  workmanship  will  develop  and  a spirit  of  pride 
will  be  fostered. 

Another  characteristic  of  the  Shuttle  operational  era  is  systems  maturity,  which  can  be  de- 
scribed as  a minimum  of  hardware  and  software  changes  and  virtually  no  unplanned  work.  Any  hardware 
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or  software  changes  will  be  driven  by  new  cargo  requirements  or  as  a result  of  Shuttle  Program  office 
direction.  Changes  should  not  be  required  to  make  the  systems  work  since  they  have  been  proven  in 
many  flights.  There  may  be  some  changes  which  have  a desirable  cost/benefit  effect,  but  these  will 
be  worked  in  such  a way  as  not  to  interfere  with  turnaround  schedules  or  to  unduly  increase  any  Shut- 
tle operations  costs.  Unplanned  work  will  be  reduced  through  adequate  advanced  planning  and  improved 
systems  reliability.  Accurate  monitoring  of  system  reliability  will  be  used  to  refine  maintenance 
and  reduce  unplanned  work  due  to  unanticipated  failures  even  further. 

Predictable  and  stable  manifests  and  launch  dates  are  necessary  in  the  Shuttle  operational  era 
and  are  a direct  result  of  good  long  range  planning.  Although  we  will  develop  greater  flexibility  to 
change  cargo  flight  assignments  and  schedule  margin  will  be  developed  to  accommodate  more  or  earlier 
launches,  lowest  cost  per  flight  can  best  be  achieved  when  manifests  and  launch  dates  are  not  often 
or  drastically  changed. 

When  unexpected  cargo  changes  do  occur  however,  the  flexibility  to  accommodate  changes  in  cargo 
manifesting  will  improve  markedly  as  the  Shuttle  Processing  team  gains  experience  with  various  pay- 
loads  and  carriers.  Advances  in  mission  planning  and  cargo  integration  have  been  made  since  the 
first  Shuttle  mission  and  are  continuing  to  be  made  today.  While  early  in  the  program  little  atten- 
tion could  be  given  to  subsequent  missions,  today's  test  team  responsibilities  are  assigned  as  much 
as  ten  missions  in  advance.  In  the  operational  era,  we  are  striving  to  ensure  that  work  instructions 
engineering,  and  parts  are  ready  months  in  advance  of  mission  turnaround  processing.  This  permits 
standardization  of  cargo  mix  options  and  optimization  of  Orbiter  reconfiguration,  facility  utiliza- 
tion, and  turnaround  support.  For  the  average  payload,  the  time  to  remanifest  will  be  reduced  from 
more  than  a year  to  approximately  three  months. 

As  Space  Shuttle  operations  become  more  repetitive  and  predictable,  a level  of  performance  mar- 
gin will  be  developed.  This  margin  does  not  accrue  directly,  but  if  managed  properly,  it  does  pro- 
vide the  Shuttle  Program  Office  the  options  to  fly  additional  missions,  to  reduce  cost  per  flight 
over  the  long  term,  or  to  respond  to  contingencies.  Capturing  the  benefits  of  this  positive  perform- 
ance margin  is  an  opportunity  requiring  skilled  innovative  management  concepts  and  techniques. 

During  the  past  two  years,  considerable  effort  has  been  spent  analyzing  Space  Shuttle  turnaround 
critical  path  constraints  and  costs.  Out  of  these  studies  have  come  design  enhancements,  test  and 
maintenance  requirements  reductions,  and  operational  improvements.  Even  before  the  Shuttle  opera- 
tional era  is  fully  achieved,  most  of  these  changes  had  been  implemented  and  this  effort  will  con- 
tinue throughout  the  upcoming  years.  The  ability  to  project  the  cost-per-f light  accurately  is  to- 
tally dependent  on  being  able  to  account  for  all  costs  correctly  through  accurate  cost  accountability 
This  requires  us  to  accurately  assess  the  impacts  of  changes  to  hardware,  software,  or  operations 
and  estimate  the  costs  of  special  services  and  mission  options  to  Shuttle  customers.  User  options 
can  be  packaged  and  priced  in  advance  to  inform  and  attract  potential  buyers. 

One  of  the  most  immediate  objectives  in  demonstrating  an  operational  Space  Shuttle  is 
establishing  a proven  launch  on  time  record.  A worldwide  reputation  for  launching  successfully  on 
schedule  is  a vital  characteristic  for  the  Shuttle  operational  era.  Our  record  has  dramatically 
demonstrated  this  capability. 

The  Shuttle  operational  era  will  be  accompanied  by  a significant  decrease  in  the  number  of  prob- 
lems encountered,  both  during  ground  operations  and  in  flight.  Improvements  in  hardware  reliability, 
personnel  training  and  certification,  and  standardization  of  operations  will  all  help  to  avoid  errors 
and  correct  inherent  system  and  design  deficiencies  or  weaknesses.  As  the  number  of  problems  de- 
crease, the  amount  of  unplanned  work  will  show  a corresponding  decrease. 

Finally,  and  importantly.  Space  Shuttle  operations  will  allow  a shift  in  the  government  manage- 
ment style.  Government  administrators,  engineers  and  scientists  are  progressing  from  the  involved 
task  of  making  the  Shuttle  work  technically  into  a reduced  role  of  overall  management  and  the  real 
business  of  making  it  pay.  Given  the  operational  Space  Shuttle,  the  proven  government-industry  team, 
the  nation's  military  and  civilian  space  programs  will  have  few  limits. 


On-Line  Operations 

One  of  the  major  functions  of  ground  turnaround  and  support  operations  is  the  hands-on  and  direct  sup 
port  activity  which  occurs  on  the  processing  line.  It  is  on  the  line  that  the  hardware  which  has 
flown  or  will  fly  is  inspected,  maintained,  repaired,  modified,  assembled  and  serviced.  Like  the  As- 
sembly Line  of  an  automobile  factory  or  the  queen's  chamber  of  a beehive,  it  is  here  that  activity 
translates  Into  productive  output.  The  transition  to  an  operational  Space  Shuttle  occurs  here  or  not 
at  all.  The  following  paragraphs  describe  some  of  key  features  of  on-line  operations: 

a)  A standard  Processing  Flow 

b)  An  Automated  Work  Control  System 
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c)  Techniques  to  handle  Time/Cycle  Repetitive  Tasks 

d)  The  Elimination  of  Duplicate  Checkout  Operations 

e)  A Reduction  in  QC  Inspection  Operations 

The  instincts  and  habits  of  Shuttle  on-line  operations  are  imbedded  in  the  standard  flow.  The 
standard  flow  consists  of  those  activities  which  must  be  performed  during  every  turnaround  regardless 
of  the  mission,  planned  configuration  changes  or  unplanned  work.  Time  is  allocated  in  the  standard 
flow  for  routine  inspections,  periodic  maintenance,  standard  reconfigurations,  routine  handling,  as- 
sembly and  servicing,  move  operations,  launch  countdown  preparations  and  launch.  Using  the  standard 
flow  as  the  base,  any  conceivable  turnaround  schedule  can  be  accurately  constructed.  Our  current 
plans  for  a standard  flow  are  depicted  in  Figure  1. 
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Figure  1.-  The  standard  flow  is  a first  step  toward  Space  Shuttle  operations. 


In  order  to  achieve  improved  Shuttle  on-line  operations,  an  automated  system  for  work  control  is 
being  developed.  There  are  many  reasons  for  automating  the  work  control  system.  Automation  facili- 
tates  standardizing  recurrent  operations  and  maintenance  instructions.  It  makes  it  easier  to  assem- 
ble work  instructions  from  a variety  of  sources  (including  the  standard  flow,  mission  planning,  con- 
figuration management,  problem  report  disposition,  etc.)  into  a coherent  practical  package.  It 
allows  us  to  provide  immediate  tracking  and  status  information.  Most  of  the  high  costs  of  distribu- 
tion, review  and  publishing  of  operation  and  maintenance  instructions  are  eliminated  because  of  the 
electronic  nature  of  the  system.  More  importantly,  however,  the  automated  work  control  system  is  a 
major  step  from  the  engineering  intensive,  "let's  feel  our  way  along"  work  authorization  and  sched- 
uling system  of  design,  development  and  test  into  the  technician  intensive,  "this  is  tried  and  true" 
work  control  system  of  the  operational  era. 

One  set  of  variants  which  affect  the  standard  flow  is  the  requirement  to  perform  time  and  cycle 
maintenance;  that  is,  maintenance  which  must  be  done  after  some  number  of  hours  of  operation  or  op- 
erating cycles.  By  scheduling  time  and  cycle  maintenance  operations  over  several  successive  flows, 
the  impact  to  any  one  turnaround  can  be  reduced.  When  planning  for  this,  allowances  must  be  made  for 
variations  in  actual  operating  times  or  cycles  from  nominal.  Through  careful  planning,  time  and 
cycle  maintenance  requirements  can  be  successfully  integrated  into  standard  flow  activities  which 
must  be  performed  every  turnaround. 

Recently,  planned  test  activities  for  STS-7  and  STS-8  were  reviewed  in  an  effort  to  eliminate  du- 
plicate checkout.  This  effort  was  successful  for  the  near  term.  In  the  long  run,  duplicate  testing 
will  be  best  eliminated  by  developing  an  integrated  checkout  system  which  satisfies  all  requirements 
for  flight  readiness  verification  in  a single  test.  This  concept  is  currently  being  analyzed  and 
reviewed  by  our  team. 
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As  technicians  become  more  experienced  and  procedures  and  instructions  are  standardized,  the  use 
of  dedicated  Quality  Assurance  Inspectors  for  inspection  verification  of  non-critical  operations  will 
not  always  be  necessary.  Today,  every  effort  is  being  made  to  eliminate  unneeded  inspections  of 
non-critical  work  and  to  transfer  the  responsibility  for  work  completion  and  quality  assurance  to  an 
ever  more  competent  technician  work  force. 


Changes  In  Launch  Team  Concepts 

Over  the  past  eight  years,  the  most  competent  launch  team  in  the  world  has  been  assembled  to 
checkout  and  launch  America's  Space  Shuttle.  This  team  has  primarily  concentrated  its  efforts  to 
working  on  a single  vehicle  or  element  at  a time.  As  we  enter  the  Shuttle  era,  members  of  that  same 
team  are  reorganizing  and  retraining  to  meet  the  challenge  of  operating  the  Shuttle  systems  at  the 
Kennedy  Space  Center  and  the  Vandenberg  Launch  Site  more  efficiently  while  maintaining  their  demon- 
strated safety  and  success  records. 

The  high  launch  rate  planned  at  the  Kennedy  Space  Center  will  encourage  assigning  processing 
teams  at  each  major  facility  - the  Orbiter  Processing  Facility,  the  Vehicle  Assembly  Building  and  the 
Launch  Pad.  During  Space  Shuttle  operations  each  facility  will  be  utilized  more  than  90%  of  the 
time,  so  each  of  these  teams  will  become  proficient  in  the  tasks  performed  at  its  facility  as  the  ve- 
hicle flow  past.  A cargo  integration  team  will  ensure  that  payload  and  cargo  requirements  are  incor- 
porated into  each  mission  turnaround  flow.  The  test  team  will  verify  flight  readiness  preparation 
and  completion  throughout  the  turnaround  process  and  will  then  perform  the  actual  launch  of  the  Shut- 
tle vehicle. 

At  the  Vandenberg  Launch  Site,  because  of  the  lower  flight  rate  and  differences  in  facility  loca 
tions  and  functional  design,  we  believe  it  is  better  to  organize  the  processing  teams  around  the  mis- 
sion and  the  flow  than  it  is  to  organize  primarily  by  facility.  This  will  cause  the  team  to  follow 
each  vehicle  through  its  processing  flow.  Although  the  processing  concepts  at  the  Kennedy  Space  Cen- 
ter and  the  Vandenberg  Launch  Site  will  be  significantly  different,  it  will  still  be  possible  to  do 
considerable  crosstraining  between  the  two  sites  since  most  of  the  common  skills  will  be  vehicle  and 
system  oriented. 


Vehicle  and  GSE  Modifications 


Various  Shuttle  missions  will  require  that  modifications  be  made  to  the  Orbiter  or  to  the  facil- 
ities and  support  equipment.  In  order  not  to  unduly  delay  turnaround  processing,  the  accomplishment 
of  these  modifications  must  be  planned  well  In  advance  of  the  mission. 

Whenever  possible,  modifications  will  be  planned  so  as  not  to  Interfere  with  standard  flow 
activities  and  repetitive  multi-flow  processing.  If  this  is  not  possible,  then  the  modifications 
must  be  done  off-line,  which  may  result  in  processing  delays.  Additional  costs  to  the  user  will  be 
associated  with  any  delays  or  special  requirements. 


Operations  Engineering 

In  order  for  the  on-line  operations  to  proceed  smoothly  and  continue  improving  in  the  opera- 
tional era,  it  is  necessary  that  a great  deal  of  analysis  and  planning  be  done.  Operations  en- 
gineering is  the  second  of  the  three  major  functions  working  together  to  attain  and  maintain  Space 
Shuttle  operations  and  will  be  the  driving  force  behind  most  of  the  following  activities. 

Few  problems  and  less  unplanned  work,  both  characteristics  of  the  operational  era,  depend  upon 
increased  system  maturity  and  hardware  reliability.  In  order  to  improve  hardware  reliability,  a 
concerted  effort  must  be  made  to  identify  the  hardware  design  changes  needed  and  schedule  their  imple 
mentation.  A system  for  tracking  and  analyzing  failures  caused  by  deficiencies  in  hardware  design 
will  be  instituted  so  that  corrections  can  be  made,  thus  forcing  systems  maturity  as  quickly  as  possi 
ble. 


Advanced  mission  planning  assures  that  mission  support  requirements  are  accounted  for  and  that 
operational  impacts  are  minimized.  The  optimum  assignment  of  Orbiters  and  scheduling  of  mission 
unique  modifications  or  special  activities  can  be  planned  in  advance.  Standard  mission  processes 
will  be  described  and  maintained  in  a Mission  Support  Plan.  Planning  for  a typical  mission  will 
start  48  months  prior  to  launch.  As  details  are  defined  and  agreed  upon,  an  Annex  to  the  Mission 
Support  Plan  will  be  developed.  A preliminary  Annex  and  schedule  will  be  ready  for  review  at  the 
Cargo  Integration  Review  13  months  before  launch  and  for  final  review  at  the  Integrated  Hardware/ 
Software  Review  8 months  before  launch.  The  approved  Mission  Support  Plan  will  be  baselined  7 
months  before  launch.  It  will  consist  of  the  standard  Mission  Plan  defining  a standard  mission 
task  list/description,  assembly  operations,  span  times,  processing  and  scheduled  maintenance  and 
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standard  flow;  and,  the  Mission  Support  Plan  Annex  containing  mission-unique  roles  and  responsibili- 
ties, mission  configuration  product  plan,  modifications,  operations  requirements,  support  require- 
ments, requirements  change  notices,  deferred/transferred  work,  vehicle  periodic  and  limited  life 
maintenance  items  and  other  changes  or  requirements  affecting  mission  span. 

Space  Shuttle  operations  requires  rigid  control  of  changes  in  order  to  hold  down  costs  and  sched- 
ule impacts  and  to  maintain  configuration  management.  Comprehensive  assessments  and  consolidated  re- 
views by  the  government  and  its  contractors  must  be  done  in  a timely  and  critical  fashion  in  order  to 
integrate  requirements  and  costs. 

The  airline  industry  has  found  from  experience  that  hardware  fails  because  of  deterioration 
through  use,  environmental  exposure,  or  because  of  accidental  damage.  An  effective  maintenance  pro- 
gram using  airline  principles  will  aid  in  preventing  failures  affecting  mission  success  or  safety  and 
will  provide  an  indication  of  inherent  hardware  maintainability  and  reliability.  When  hardware  per- 
formance is  not  acceptable,  as  uncovered  by  an  analysis  of  the  consequences  of  failure  and  proposed 
corrective  tasks  - such  as  more  frequent  lubrication  - then,  hardware  redesign  may  be  necessary. 
Through  continuous  feedback  from  on-line  Shuttle  processing  operations,  flight  and  ground  hardware 
can  methodically  be  redesigned  to  give  acceptable  reliability  with  improved  maintainability  at  mini- 
mum cost.  This  principle  is  referred  to  as  reliability  centered  maintenance  (RCM).  The  application 
RCM  to  Space  Shuttle  operations  will  reduce  test  requirements.  A part  of  the  RCM  principle  is  an 
analysis  of  function  criticality  and  time-cycle  periodicity.  As  these  are  better  understood,  test 
requirements  can  be  reduced  to  a minimum. 

Anomalies  that  occur  in  flight  must  be  analyzed  during  the  mission  so  that  fault  isolation  proce- 
dures  can  be  scheduled  and  completed  within  the  time  frame  of  the  next  turnaround.  In  Space  Shuttle 
operations,  line  replaceable  unit  removal,  replacement  and  retest  will  be  standardized  and  packaged 
so  that  unscheduled  maintenance  can  be  folded  into  the  planned  turnaround  flow  with  least  impact.  The 
analysis  of  flight  data  will  be  improved  through  the  development  of  better  flight  and  ground  diagnos- 
tic capabilities. 

One  operational  objective  is  the  standardization  of  the  software  development  cycle.  Software 
will  be  modularized  and  streamlined  to  allow  automatic  updating  of  the  software  when  required  by  mis- 
sion peculiar  data  or  modifications.  Individual  system  engineers  will  continue  to  have  overall  re- 
sponsibility for  development  and  maintenance  of  the  application  software  they  use,  continuing  the  con- 
cept that  eliminates  the  software  "middleman". 

As  technicians  and  inspectors  become  more  experienced,  and  as  systems  designs  are  made  more  sta- 
ble and  are  better  understood,  the  procedures  to  make  certain  kinds  of  repairs  can  be  standardized. 
"Standard  repairs"  can  be  performed  when  required  without  engineering  analysis  or  evaluation  and  will 
be  available  at  the  work  station  for  implementation  at  any  time  with  the  cognizance  of  the  responsi- 
ble supervisor  or  master  technician. 

Modifications  to  satisfy  mission  or  safety  requirements  are  considered  mandatory.  An  approved 
change  is  a direct  constraint  to  flight  if  It  will  prevent  or  delay  vehicle  processing  or  if  it  will 
allow  an  unacceptable  safety  risk  to  exist.  The  completion  and  accomplishment  of  changes  are 
synchronized  with  vehicle  processing  and  facility/support  equipment  activities  so  as  not  to  be 
a constraint  to  flight. 


Support  Operations 

The  final  part  of  the  Space  Shuttle  operation  is  Support  Operations.  This  encompasses  spares 
management,  line  replaceable  unit  maintenance,  shops  and  labs,  training,  certification  and  facilities 
activation. 

The  spares  program  will  review  requirements  for  ground  and  flight  element  spares  against  present 
inventories^  Deficiencies  will  be  corrected  through  direct  procurement  activities.  In  October  1985, 
spares  requirements  and  inventories  will  be  automated  with  the  Shuttle  Inventory  Management  System  II 
(SIMS  II).  This  system  will  be  linked  to  the  automated  work  control  system  and  will  provide  end-to- 
end  control  and  visibility  of  spares  from  supplier  to  process  user. 

Flight  element  spares  repair  and  maintenance  will  be  the  responsibility  of  the  design  centers. 

The  Kennedy  Space  Center  and  the  Vandenberg  Launch  Site  will  provide  inputs  on  Line  Replaceable  Unit 
(LRU)  maintenance  requirements  and  on-site  capabilities.  Repair  and  maintenance  of  ground  systems  and 
facilities  LRU's  will  be  done  in  the  shops  and  labs  at  the  launch  sites.  The  shops  and  labs  will  be 
consolidated  and  integrated  to  eliminate  duplication  and  make  the  best  use  of  them. 

Increased  classroom  and  on-the-job  training  for  technicians  will  allow  them  to  assume  added 
responsibilities  for  tasks  presently  requiring  on-line  support  from  engineering  or  professional  per- 
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sonnel.  A master  technician  certification  will  distinguish  those  who  have  completed  all  required 
training  and  demonstrated  superior  proficiency. 

Fundamental  to  Space  Shuttle  operations  is  completion  of  construction  and  activation  of 
facilities  at  the  Kennedy  Space  Center  and  the  Vandenberg  Launch  Site.  The  delivery  of  the  full 
Orbiter  fleet  and  operational  readiness  of  all  the  planned  facilities  will  usher  in  the  new  era 
in  space  transportation. 


APPROACH  TO  ACHIEVING  SPACE  SHUTTLE  OPERATIONAL  CAPABILITY 


In  order  to  progress  to  the  desired  level  of  Space  Shuttle  operations,  it  is  necessary  to  quan- 
tify the  characteristics  into  achievable  performance  objectives.  Instead  of  just  saying,  "lower  cost 
per  flight  is  an  operational  era  characteristic",  a goal  must  be  set  which  will  make  the  Shuttle  com- 
petitive; such  as  $25  million  per  average  flight  by  fiscal  year  1987.  Next,  a plan  for  the  perform- 
ance improvement  needed  to  progress  from  the  present  to  the  desired  must  be  prepared.  This  must  be 
done  for  each  relevant  parameter.  Shuttle  operations  is  dependent  on  many  interrelated  parameters 
each  of  which  must  be  controlled  in  order  to  achieve  operational  status.  Each  must  be  managed  stead- 
ily in  order  to  move  into  Space  Shuttle  operations  according  to  plan. 


Milestone  Tasks 


The  completion  of  the  following  twelve  tasks  is  key  to  achieving  near  term  Space  Shuttle  Proc- 
essing objectives.  The  overall  intent  of  these  Milestones  is  to  be  complete  at  the  Kennedy  Space 
Center  before  October,  1984  and  at  the  Vandenberg  Launch  Site  before  October,  1986.  We  at  Launch 
Operations  are  actively  pursuing  these  objectives. 

1.  Implementation  Of  The  Standard  Flow.  In  order  to  implement  the  standard  flow,  the  opera- 
tions and  maintenance  instructions  required  for  every  flow  must  be  defined.  At  the  same  time,  the  on- 
line processing  work  stations  must  be  established  and  the  job  card  system  of  work  control  must  be 
implemented.  Finally,  the  standard  flow  operations  and  maintenance  instructions  will  be  converted 
into  job  cards  and  put  in  the  work  control  system  for  use.  The  standard  flow  assessment  is  currently 
being  reviewed  and  will  be  released  and  maintained  in  the  Mission  Support  Plan.  The  standard  flow 
for  0V-099  as  shown  earlier  in  Figure  1,  will  be  implemented  for  STS-13  in  April,  1984. 

2.  Work  Control  Automation.  Automating  the  work  control  system  requires  converting  from  the 
present  system  and  integrating  the  hardware  and  software  required  to  do  the  job.  A considerable  in- 
formation management  system  interface  will  be  required,  but  we  expect  this  will  be  finished  by  May, 
1985. 


3.  Test  Team  Organization  and  Training.  The  Shuttle  processing  contractor  will  assume  the  NASA 
Test  Director  role  and  will  be  fully  trained  and  organized  for  Space  Shuttle  operations  by  September, 
1984.  Training  of  Vandenberg  Launch  Landing  Site  personnel  will  be  completed  in  April,  1986, 

4.  Mission  Planning.  The  Mission  Support  Plan  processing  will  be  operational  and  automated  by 
December,  1984.  This  plan  will  provide  a detailed  description  and  schedule  of  all  work  to  be 
performed  for  a particular  flow  and  will  become  the  backbone  of  our  Processing  operations. 

5.  Change  Control.  We  plan  to  eliminate  redundant  change  boards  and  combine  necessary  change 
board  functions  into  one  or  two  board  for  greater  control  and  effectiveness.  This  will  be  complete 
for  the  Kennedy  Space  Center  by  October,  1985  and  for  the  Vandenberg  Launch  Site  in  October,  1986. 

6.  Software.  By  October,  1986,  ground  processing  software  will  have  been  standardized  and 
integrated  with  an  automated  centralized  data  base.  Software  changes  should  become  relatively  few 
and  far  between. 

7.  Requirements  Reduction.  A significant  operational  requirements  will  have  been  put  into 
effect  through  reliability  centered  maintenance  (RCM)  by  December,  1985.  This  will  be  a key  item 
in  our  attainment  of  the  Standard  Flow. 

8.  Spares.  Buildup  of  inventories,  procurements  of  new  hardware  and  any  transfer  of  respon- 
sibilities will  be  completed  in  April,  1986.  This  will  involve  a significant  increase  in  funding 
if  the  program  is  to  continue  at  its  current  rate. 

9.  Line  Replacement  Unit  Maintenance.  In  April,  1986  all  tradeoff  analyses  will  have  been 
completed,  all  required  shops  will  be  on-line  and  any  transfers  of  responsibilities  shall  have  been 
made.  KSC  will  become  a true  Shuttle  maintenance  base,  capable  of  repairing  many  vehicle  LRU's. 
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10.  Training.  Necessary  training  programs  will  be  operational  by  December,  1984  at  the  Kennedy 
Space  Center  and  by  July,  1985  at  the  Vandenberg  Launch  and  Landing  Site.  The  Master  Technician  cer- 
tification, similar  to  an  aircraft  A&E  license,  will  be  in  effect  in  August,  1984. 

11.  Facility  Activation.  Operational  readiness  dates  at  the  Kennedy  Space  Center  are:  Launch 

Pad  B December,  1985;  and  Mobile  Launch  Platform-3  (MLP-3)  October,  1986.  At  the  Vandenberg  Launch 
Site  activation  is  fully  complete  in  May,  1985.  These  dates  are  crucial  to  achieving  full  capability 
for  the  Shuttle  System  and  we  will  work  hard  to  ensure  they  are  met. 

12.  0V-103  Processing.  The  first  flight  from  the  Vandenberg  Launch  Site  (VLS)  is  the  seventh 
flight  of  0V-103.  VLS  personnel  will  participate  in  turnaround  processing  of  STS-19,  21  and  23  at 
the  Kennedy  Space  Center  (KSC)  for  familiarization.  0V-103  will  be  processed  through  the  Orbiter 
Processing  Facility  and,  if  necessary,  the  hypergolic  maintenance  facility  at  KSC  and  then  ferried 
from  Florida  to  California  for  the  first  three  VLS  launches.  VLS  personnel  will  assume  increasing 
responsibility  during  each  of  these  last  three  turnarounds  of  0V-103  at  KSC. 


CHALLENGES  TO  ACHIEVING  THE  OPERATIONAL  ERA 


There  are  definite  problems  facing  the  government/industry  Shuttle  team  as  we  proceed  towards 
our  goal.  The  greatest  threat  to  achieving  the  promise  of  the  Shuttle  operational  era  are  circum- 
stances which  could  totally  halt  or  impede  orderly  processing.  The  Shuttle  Processor  must  be  able 
to  prevent  or  quickly  recover  from  these  occurrences.  Today,  there  are  two  challenges  menacing  the 
achievement  of  the  operational  era  which  are:  adequate  hardware  spares  and  a line  replaceable  unit 

(LRU)  maintenance  program;  and,  acceptable  reliability  of  flight  hardware  and  ground  support  equip- 
ment. It  is  an  intolerable  situation  if  serial  processing  time  is  constantly  lost  because  of  hard- 
ware failure  or  the  lack  of  replacement  parts.  The  challenge  to  force  increased  hardware  reliability 
and  provide  adequate  backup  capability  will  require  increased  financial  support  from  the  Congress  and 
the  agency  if  a major  interruption  in  Shuttle  service  is  not  to  occur.  We  believe  it  is  the  greatest 
challenge  currently  facing  the  Space  Transportation  System. 


CRITICAL  MILESTONES  AND  PLAN  OF  ACTION 


We  have  outlined  a concept  and  plan  that  we  believe  will  carry  us  quickly  into  a truly  opera- 
tional Space  Transportation  System. 

The  place  of  action  is  simple.  We  must  press-on,  on  the  course  we  have  plotted,  to  make  the 
dream  of  the  ' 70 1 s the  reality  of  the  '80's.  Safe,  affordable,  reliable  operations  in  space  for  the 
free  world  using  an  advanced  Space  Transportation  System  and  a reusable  Space  Shuttle  Orbiter  are 
truly  within  our  grasp. 
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LAUNCH  PROCESSING  SYSTEM 
CONCEPT  TO  REALITY 


William  W.  Bailey 
Digital  Electronics  Division 
Engineering  Development  Directorate 
Kennedy  Space  Center,  Florida 


ABSTRACT 


The  Launch  Processing  System  represents  Kennedy  Space  Center's  role  in  providing  a major 
integrated  hardware  and  software  system  for  the  test,  checkout  and  launch  of  a new  space  vehicle. 

Past  programs  considered  the  active  flight  vehicle  to  ground  interfaces  as  part  of  the  flight  systems 
and  therefore  the  related  ground  system  was  provided  by  the  Development  Center.  This  paper  addresses 
the  major  steps  taken  to  transform  the  Launch  Processing  System  from  a concept  to  reality  with  the 
successful  launches  of  the  Shuttle  Programs  Space  Transportation  System. 


CONCEPT  DEFINITION 


With  the  baselining  of  the  Space  Shuttle  Program,  NASA  was  faced  with  the  technical  challenge  of 
processing  and  launching  a new  type  of  space  vehicle.  In  1972,  a task  group  was  formed  at  KSC  to  re- 
view the  checkout  requirements  of  the  Shuttle  elements  and  to  recommend  to  Shuttle  Management  a check- 
out system  which  would  satisfy  all  processing  requirements  and  meet  the  initial  April,  1978  launch 
date. 


Initial  system  sizing  was  based  on  a comparative  analysis  of  analog  and  discrete  measurement  and 
stimuli  data  parameters  between  Apollo  and  Shuttle  ground  and  on-board  systems  (Table  I).  This  1972 
analysis  indicated  for  initial  Shuttle  and  envelopment  flights,  the  total  number  of  parameters 
(Operational  Flight  and  Development  Flight  Instrumentation)  was  approximately  the  same  as  Apollo 
ground  and  on-board  systems. 


TABLE  I.-  COMPARISON  BETWEEN  APOLLO  AND  SHUTTLE  DATA  PARAMETERS  IN  1972 


APOLLO 

SHUTTLE  (1972) 

ELEMENTS 

PARAMETERS 

ELEMENTS 

PARAMETERS 

SPACECRAFT 

2101 

ORBITER 

OFI 

2300 

DFI 

2800 

PAYLOAD 

230 

— 

LAUNCH  VEHICLE 

3188 

SSME  SRB  ET 

1076 

256 

GROUND  SUPPORT 
EQUIPMENT 

4038 

GROUND  SUPPORT 
EQUIPMENT 

1787 

— 

TOTAL 

9327 

SUB  TOTAL 
TOTAL 

5393 

8449 

3056 

To  meet  the  rapid  turnaround  time  requirement  of  a reusable  vehicle  as  well  as  to  significantly 
reduce  the  number  of  people  involved,  the  entire  launch  processing  activity  had  to  be  automated  with 
digital  computers.  It  had  to  be  done  in  such  a way  to  preserve,  from  a functional  point  of  view,  the 
test  engineers  direct  control  over  checkout  and  launch  procedures.  Therefore,  a highly  functional, 
user-friendly  hardware  and  software  interface  between  the  user-engineer  and  the  system  was  necessary. 
The  system  had  to  be  modular  to  handle  the  various  checkout  areas  which  included  not  only  the  inte- 
grated vehicle  testing  and  launch,  but  also  the  checkout  of  the  individual  Shuttle  elements;  i.e., 
Orbiter,  External  Tank,  and  Solid  Rocket  Boosters. 

Other  factors  which  entered  into  the  review  process  included  such  areas  as: 

1)  Use  of  existing  Apollo  Checkout  Equipment  (ACE) 

2)  Use  of  newly  development  systems  proposed  for  use  during  Orbiter  manufacturing  phase  and  the 
development  and  operational  phase.  Examples  of  these  included  Unified  Test  Equipment  (UTE)  and  a Uni- 
versal Control  System  (UCS). 
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3)  Development  of  a new  Launch  Processing  System 

4)  Phased  implementation  involving  the  use  of  an  existing  system  during  the  development  flight 
period  and  a new  system  for  the  operational  phase. 

Based  on  a thorough  examination  of  all  the  known  factors  the  decision  was  made  to  implement  a 
new  concept  for  the  automated  checkout  and  launch  of  the  Space  Shuttle. 


CONCEPT  DEVELOPMENT 


In  March,  1973,  a civil  service  team  was  formed  at  KSC  under  the  Design  Engineering  Directorate 
to  develop  the  Launch  Processing  System  (LPS)  concept  and  to  provide  the  systems  engineering  and  inte 
gration  required  to  implement  the  system.  By  October,  1973,  the  "LPS  Concept  Description  Document" 
was  released  which  described  an  integrated  checkout  and  launch  facility  capable  of  controlling  the 
Ground  Support  Equipment  (GSE)  and  Orbiter  thru  consoles  and  interfaces  using  a distributed  process- 
ing scheme.  The  LPS  involved  two  major  elements;  the  Central  Data  Subsystems  (CDS)  and  the  Checkout, 
Control  and  Monitor  Subsystems  (CCMS).  The  Central  Data  Subsystem  (CDS)  would  provide: 

o Real  time  data  recording  and  recall 
o Engineering  technical  file 
o Work  authorization  and  control 
o Pre/post  test  data  analysis 

o Support  software  and  application  program  library  for  the  LPS  checkout  system 
o Simulation  for  software  validation  and  operator  training 

The  Checkout,  Control  and  Monitor  Subsystem  (CCMS)  involved  a modular  component,  or  building 
block,  concept  which  allowed  LPS  components  to  be  specified  at  an  early  date  and  then  configured  in 
various  ways  to  accommodate  the  evolving  Shuttle  program  requirements  and  the  different  levels  of  com 
plexity.  Figure  1 depicted  the  LPS  launch  support  configuration  which  involved  the  use  of  the  follow 
ing  modular  components: 

o Consoles  for  command  and  monitor  of  subsystem  functions  within  an  assigned  discipline,  such 
as  LOX,  LH2,  GN&C,  ECS,  Payloads 

o Hardware  Interface  Modules  (HIMs)  for  interfacing  with  Ground  Support  Equipment  (GSE),  such 
as  LOX,  LH2,  Hazardous  Gas  Detection,  Tail  Service  Masts 

o Front  End  Processors  (FEPs)  for  receiving  data  in  the  LCC  and  producing  a compact  computer 
process  oriented  measurement  list  and  storing  the  preprocessed  data  in  the  CDBFR 

o Common  Data  Buffer  (CDBFR)  for  providing  shared  memory  for  all  system  data  and  interconnect- 
ing all  distributive  processors  required  to  transfer  data,  commands  and  computer  to  computer  messages 
o Processed  Data  Recorder  and  Stored  Peripheral  Area  (PDR/SPA)  where  raw/processed  data  and  com 
mands  are  logged  for  near  real  time  or  post  test  analysis 

o Timing  subsystem,  where  countdown  and  real  time  clock  times  are  generated  and  controlled 

Other  configurations  envisioned  in  the  concept  document  included  the  following: 

o Maintenance  and  checkout  area 
o ET  and  SRB  "Free  Standing"  areas 

The  Application  Programs  executed  in  the  consoles  would  be  written  in  a higher  order  engineering 
language  referred  to  as  GOAL  (Ground  Oriented  Aerospace  Language).  These  programs  would  provide  the 
required  test/operations  sequencing,  command/control,  systems  monitoring,  displays,  interlocks  as 
defined  by  the  test  engineers,  and  hardware  constraints.  The  programs  would  be  written  by  the  user/ 
operator  of  the  particular  subsystem  being  monitored  and  controlled  by  the  CCMS.  The  programs  would 
be  compiled  on  the  CDS  for  execution  of  the  subsystem  console  by  the  user/operator.  The  various 
subsystems  could  be  operated  in  parallel  but  independently  of  each  other. 

The  LPS  concept  description  document  was  used  very  successfully  by  the  design  team  to  conduct 
overall  concept  design  review  meetings  with  users  at  KSC  and  with  MSFC  and  JSC  personnel.  In  paral- 
lel to  these  reviews,  the  design  team  generated  in  April,  1974,  the  LPS  Station  Set  Requirements  Docu 
ment  which  identified  all  Shuttle  Level  II  programs  and  other  functional  requirements  levied  upon  the 
LPS. 


CONCEPT  IMPLEMENTATION 


The  contractual  implementation  approach  involved  the  use  of  four  major  contracts:  (1)  System 

Engineering  and  Software  Development;  (2)  Minicomputers;  (3)  CCMS  Hardware  using  GFE'd  mini- 
computers; and  (4)  Central  Data  Subsystem  Hardware  and  Software.  The  phasing  of  these  contracts  is 
shown  in  Figure  2. 
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Figure  1.-  Launch  Support  Configuration  (Circa  1973). 


Figure  2.-  LPS  Contracts. 


SYSTEM  ENGINEERING  AND  SOFTWARE  DEVELOPMENT 

In  May,  1974,  IBM  was  selected  by  NASA  to  provide  the  System  Engineering  and  Software  Develop- 
ment for  the  LPS  This  selection,  prior  to  hardware  and  computer  procurement,  allowed  a total  system 
design  to  be  put  in  place  for  the  LPS  as  contrasted  to  previous  programs  where  the  hardware  was  se- 
lected first  and  the  software  was  then  required  to  fit  a "comm it ted -to"  system  architectural  design. 
Numerous  trade  studies  were  conducted  by  the  government/contractor  team  to  determine  the  allocations 
of  processing  functions.  The  results  of  these  studies  were  tested  and  simulated  to  predict  the  ef- 
fectiveness and  performance  of  each  key  decision.  In  parallel  to  this  activity,  NASA  was  performing 
in-house  component  design  and  prototyping  of  key  hardware  elements.  These  included  such  critical 
areas  as  the  Common  Data  Buffers  (CDBFR);  man-machine  interfaces  involving  keyboards,  color  CRT's, 
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programmable  function  panels,  hard  copy  devices,  safing  panels;  data  acquisition,  transmission  and 
sensors;  and  distributed  computer  systems.  The  CCMS  Systems  Engineering  review  and  prototype  develop 
ment  culminated  in  selection  of  a distributive  minicomputer  network  architecture  which  would  support 
up  to  64  minicomputers  or  microprocessors  to  share  a common  64K-word,  high-speed  pipeline  memory  to 
communicate  with  each  other.  These  computers  perform  basically  the  following  functions: 

(1)  Man-machine  interfaces  at  a console  work  station. 

(2;  Interface  with  Ground  Support  Equipment  to  insure  commands  and  monitor  and  limit  check 
measurements. 

(3)  Interface  with  the  Orbiter  on-board  computers  via  the  Launch  Data  Bus 

(4)  Interface  with  the  Orbiter  command  uplink  subsystem. 

(5)  Record  transactions  in  the  64K  shared  memory. 

(6)  Provide  the  capability  to  retrieve,  format  and  print  these  prerecorded  transactions. 


CCMS  HARDWARE 

In  June,  1975,  Modular  Computer,  Inc.  was  selected  to  provide  commercial  mini -computers  (MODCOMP 
11/45)  for  the  operational  systems.  In  August,  1975,  Martin  Marietta  Corp.  (MMC)  was  selected  to  pro 
vide  the  design,  fabrication,  test  and  installation  of  the  CCMS  hardware.  By  November,  1976  (fifteen 
months  later),  the  initial  set  of  hardware,  "Serial-0",  was  delivered  to  KSC  to  support  the  opera- 
tional software  development  by  IBM.  By  February,  1977,  a subset  of  CCMS  hardware  and  operating  soft- 
ware was  made  available  to  the  system  users/operators  to  support  their  application  program  software 
development  using  the  higher-order  language  Ground  Oriented  Aerospace  Language  (GOAL).  Other  CCMS 
sets  initially  implemented  included  the  following  locations: 

o Shuttle  Avionics  Integration  Labs  at  JSC 
o Hypergolic  Maintenance  Facility  at  KSC 
o Launch  Control  Center  Firing  Rooms  1 & 2 at  KSC 
o KSC's  Complex  Control  Center 


CDS  HARDWARE  AND  SOFTWARE 

Proceeding  in  parallel  with  the  CCMS  procurement  and  delivery  activities,  the  fourth  major  LPS 
contract  was  awarded  to  Honeywell,  Inc.  for  the  Central  Data  Subsystem  computers  and  software  sup- 
port. The  initial  phase  of  CDS  hardware  was  delivered  in  early  1976  and  installed  in  the  Launch 
Control  Center.  The  basic  configuration  involved  two  dual  66/80  Honeywell  CPU's  sharing  a megaword 
of  memory.  These  computers  were  interfaced  to  the  following  primary  hardware  subsystems: 

o Real-Time  Interface  (RTIF)  used  to  format  CCMS  CDBFR  data  for  real  time  recording  on  CDS 

o Video  Simulation  Interface  (VSI)  used  to  simulate  data  into  the  CCMS  in  support  of  CDS 
modeling  of  ground  and  on-board  systems 

o Communication  Processors  for  interfacing  with  CCMS  consoles  and  engineering  terminals  LPS  Ap- 
plication Programs 


LPS  APPLICATION  PROGRAMS 


The  development  of  the  software  required  to  automate  the  processes,  control  mechanisms  and 
testing  procedures  for  checkout  and  launch  of  the  STS  involved  the  many  users  of  LPS.  Each  user  was 
responsible  for  creating,  modifying  and  controlling  his  software,  which  included  the  application 
programs,  test  display  skeletons,  control  logic  sequences,  and  Test  Control  Supervisor  (TCS)  sequence 
procedures.  The  following  represents  the  number  of  procedures  and  computer  size  words  used  by  the 
user  for  vehicle  and  ground  test: 


User  Software 


# Procedures 


Total  Word  Size 


GOAL  Programs 

1381 

Display  Skeletons 

563 

Control  Logic  Sequences 

220 

Test  Control  Supervisors 

51 

14,230,272 

608,040 

13,170 

56,890 


EVOLVING  REQUIREMENTS 


From  the  time  that  the  initial  set  of  hardware  was  delivered  until  the  launch  of  STS-1,  numerous 
changes  occurred  which  could  have  impacted  the  LPS  Operational  Readiness  Date  (ORD)  if  it  had  not 
been  for  the  flexibility  and  modularity  of  the  system  hardware  and  software  architecture.  Some  of 
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the  primary  changes  were: 

o Growth  in  vehicle  and  ground  support  equipment  parameters  from  initial  1972  estimated  of 
°14,000  OFI/DFI  measurements  to  41,000 

o Bulk  Memory  addition  to  the  consoles 

o TCS  Compiler/Loader  (GOAL  On  , Board  IF) 

o Safing  & Biomedical  System 

o Monitor  Consoles  in  support  Firing  Room 

o Huntsville  Operating  Support  Center  (HOSC)  Interface  to  MSFC 

o FEP  Expansion  to  handle  PCM/GPC  formats 

o Orbiter  Computational  Facility  for  processing  Mass  Memory  Load  Tapes 
o Processing  of  Non-Standard  Data  Types 
o Real  Time  Diagnostics 

The  Firing  Room  LPS  configuration  which  supported  the  launch  of  STS-1  consisted  of  41  minicom- 
puters and  4 microprocessors  actively  communicating  through  the  Common  Data  Buffer.  An  additional  8 
CPU's  in  FR2  were  actively  connected  to  the  same  CDBFR  in  a data  monitoring,  engineering  support 
role.  The  1973  LPS  concept  depicted  in  Figure  1 had  become  a reality. 


REALITY 


The  Launch  Processing  System  successfully  supported  the  checkout  and  launch  of  the  first  reus- 
able Space  Transportation  System  in  April,  1981.  Since  this  was  the  first  launch,  the  NASA/IBM 
engineering  team  performed  post  processing  analysis  of  the  data  processed  by  the  CCMS  FR  #1  computers 
during  terminal  countdown  to  evaluate  system  performance.  Areas  measured  included  the  following: 

o Processed  Data  Recorders  (PDR)  FIFO/Logging  activity  as  a measure  of  computer  comnunication 
activity  across/through  the  Common  Data  Buffer  (CDBFR).  (Excessive  logging  could  result  in  loss  of 
recorded  data) 

o Computer-to-computer  (C-C)  activity 

The  PDR  FIFO/Logging  rate  to  disk  and  tape  for  STS-1  experienced  31K-word  pairs  in  one  second 
during  the  terminal  count  against  a design  limit  of  33K-word  pair  per  second.  Prior  to  STS-2,  CCMS 
S/W  modifications  were  incorporated  which  raised  the  loss-of-data  rate  to  58K-word  pairs  of  logging. 
Figure  3 provides  the  highest  logging  rates  and  the  tape  switchover  rate  for  STS-1  thru  STS-6. 

The  maximum  number  of  computer-to-computer  (C-C)  transactions  per  second  which  the  CCMS  could 
handle  across  the  CDBFR  was  determined  prior  to  STS-1  to  be  670.  This  number  represented  the  maximum 
system  load  before  loss  of  logged  data  occurs.  Figure  4 depicts  the  maximum  C-C's  per  second 
encountered  during  STS-1,  2,  3,  and  6 terminal  counts. 
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Figure  3.-  PDR  Logging  Rates  (Maximum)  During  STS  Terminal  Count. 


Since  the  launch  of  STS-1,  a significant  number  of  changes  have  been  incorporated  in  LPS  due  to 
vehicle  and/or  ground  changes.  Examples  of  these  are  listed  below.  The  changes  were  implemented 
without  impacting  the  system  architecture  which  again  demonstrated  the  flexibility  and  modularity  of 
the  hardware  and  software  elements. 

o Console  Memory  Margins  Requiring  GOAL  Rewrite 
o DOD  Payload  Security 
o Launch  Data  Bus  FEP 
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STUDY  LIMIT 

Figure  4.-  Maximum  C-to-C  In  a Second  During  STS  Terminal  Count. 


o Application  Program  Growth  Affect  Disk  Sizing 
o Payload  FEP  addition 
o Data  Bank  Restructure 

o Engineering  Support  Assembly  Data  Display  Rates 
o Format  changes  affecting  FEP  memory  sizing 


OPERATIONAL  ASSESSMENT 


In  January,  1981,  KSC  initiated  a 9-month  study  which  addressed  the  required  performance  of  all 
LPS  elements  during  the  Shuttle  operational  era.  An  indepth  analysis  of  all  off-line  and  on-line  LPS 
processes  required  to  support  vehicle  testing,  checkout,  launch  and  landing  was  conducted.  Signifi- 
cant recommendations  which  are  resulting  in  system  changes  today  are  as  follows: 

o Restructure  Data  Bank  to  make  it  less  sensitive  to  vehicle  changes  or  mission-to-mission 
changes 

o Restructure  Test  Configured  Identification  (TCID)  Build  and  Load  processes  to  allow  easier 
changes  and  on-line  mods 

o Enhance  software  build  processes  to  improve  quality  and  documentation  of  outputs 
o Add  equipment  which  allows  Firing  Room  Sets  to  be  split  to  perform  multiple  tasks 
o Add  capability  to  conduct  STS  element  (off-line)  tests  from  the  Software  Production  Facility 
(FR2)  to  off-load  FR1  & 3 integrated  tests  and  launch  activities 

o Enhance  O&M  functions  to  reduce  system  down-time  and  reconf iguration  times 

As  the  Space  Transportation  System  moves  into  its  operational  phase,  KSC  has  reviewed  the  LPS 
for  any  potential  hardware  areas  which  could  affect  system  performance.  This  review  has  included 
available  memory  margins,  maintainability/spares  availability,  etc.  Two  areas  are  currently  under 
review;  the  first,  memory  margins  in  the  console  minicomputers  and  second,  the  repair  problems  asso- 
ciated with  the  console  128K  extended  bulk  memory.  The  console  CPU  main  memory  is  limited  by  design 
to  only  64K  words  with  only  100  unused  words  (<1%).  One  major  software  upgrade  to  the  GOAL  exec- 
utive has  been  performed  which  yielded  1300  additional  locations.  Subsequent  changes  have  reduced 
the  margin  to  the  current  figure  and  another  software  modification  to  reclaim  additional  memory  is 
not  advised.  To  offset  the  potential  risk  of  exceeding  current  CPU  capacity,  KSC  has  developed  an 
emulator  (with  up  to  2M  words  of  executable  main  memory)  which  can  replace  a Modcomp  11/45  and  its 
associated  bulk  memory  in  any  console  configuration  and  support  all  required  functions  without 
requiring  all  CPU's  in  a particular  set  to  be  upgraded  at  the  same  time.  With  the  availability  of 
this  capability  in  October,  1984,  the  Launch  Processing  System  will  be  capable  of  supporting  the 
Space  Transportation  System  well  into  the  1990 's. 


OPERATIONAL  SYSTEMS 


Today,  twelve  LPS  systems  are  operational  with  two  additional  planned  for  the  future.  The  sets 
are  located  not  only  at  KSC  but  also  on  the  Eastern  Test  Range  (ETR)  in  support  of  DOD  payload  pro- 
cessing, at  JSC  in  support  of  Orbiter  avionics  to  ground  interface  testing,  and  at  Vandenberg  Air 
Force  Base  in  support  of  Shuttle  and  DOD  payload  testing,  checkout  and  launch  from  the  West  Coast. 
Capabilities  are  being  added  which  allow  data  communcation  between  individual  CCMS  sets,  such  as  a 
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VAFB  set  and  a KSC  Firing  Room  set.  The  CCMS  sets  have  been  optimized  for  the  functions  which  they 
are  required  to  support.  The  distributive  minicomputers  and  microprocessors  connected  to  a CDBFR 
vary  from  two  in  the  Air  Force's  Orbiter  Functional  Simulator  to  as  many  as  forty-five  in  a full-up 
Firing  Room.  The  operational  software  is  modular  and  can  support  all  CCMS  sets  without  requiring  in 
dividual  releases. 


SUMMARY 


Through  the  dedicated  and  competent  efforts  of  a NASA  civil  service  and  contractor  team,  the 
Launch  Processing  System  has  been  brought  from  concept  to  operational  support.  The  Launch  Processing 
System  is  a very  integral  and  key  element  of  the  Space  Transportation  System.  LPS  is  supporting  the 
Shuttle  processing  very  successfully  and  shall  continue  in  its  support  role  as  processing  timelines 
are  reduced  to  achieve  the  Shuttle  Operational  Era  goals.  It's  demonstrated  flexibility  and  modular- 
ity will  allow  it  to  continue  to  be  adapted  to  unforeseen  and  changing  program  requirements.  As  we 
move  toward  the  future,  the  distributive  computer  architecture  employed  in  LPS  will  serve  as  a corner- 
stone for  evaluating  other  systems  as  they  are  conceived  and  become  a reality. 
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AUTOMATIC  SOFTWARE  FOR  CONTROLLING  CRYOGENIC  SYSTEMS 


James  W.  Rudolph* 
Martin  Marietta  Corporation 
Kennedy  Space  Center 


ABSTRACT 


This  will  be  a technical  discussion  of  the  lessons  learned  during  the  seven  years  of  software 
development/testing  which  occurred  on  the  Liquid  Oxygen  System  for  the  Space  Shuttle  at  KSC.  Prob- 
lems which  were  solved  during  these  years  came  into  four  distinct  phases:  design/debug  before  simula- 

tion runs,  verification  using  simulation  with  models  up  through  STS-1  launch,  hardware  usage  from 
first  launch  to  STS-5  launch,  future  use  (integrated  automation,  VAFB).  Each  problem/solution  will 
describe  the  apparent  problem  requirements/constraints,  usable  alternatives,  selected  action, 
results. 


INTRODUCTION 


Seven  years  ago,  NASA  contracted  the  Martin  Marietta  Corporation  to  hire  systems  engineers  to 
work  in  the  Liquid  Oxygen  (LOX)  storage  area  of  Launch  Complex  39  for  the  purpose  of  servicing  the 
hardware  required  to  support  the  Space  Shuttle.  The  commonly  accepted  definition  of  system  engineer- 
ing duties  outlined  a rather  clear  guideline  for  management  as  they  went  about  hiring  the  finest 
available  talent.  Cryogenic  experts,  field  engineers,  eager  college  graduates,  Saturn  veterans,  all 
were  interviewed.  Both  interviewer  and  prospect  didn't  need  to  discuss  task  definition  and,  there- 
fore, concentrated  more  on  job  qualifications.  After  all,  a LOX  systems  engineer  was  to  write 
procedures  to  maintain  and  operate  the  LOX  hardware. 

This  was  no  simple  task  but  by  the  same  token  this  hardware  was  15  years  old  by  design  and  not 
as  complex  as  some  state-of-the-art  facilities.  A working  system  of  valves,  pipes,  pumps,  trans- 
ducers, controllers,  and  pneumatics  was  inherited  from  the  Saturn  program.  The  task  seemed  even 
easier  considering  the  10,000  GPM  pumping  system  was  not  to  be  used,  only  one  LOX  stage  had  to  be 
filled  instead  of  three  and  the  existing  procedures  were  made  available  by  the  Government  from  a 
previous  contractor.  The  Space  Shuttle  philosophy  made  promises  of  being  more  operational  by 
reducing  the  amount  of  maintenance  and  redundancy  of  less  critical  components,  thus  reducing  the 
day-to-day  work  load  of  the  systems  engineer.  The  people  selected  for  the  original  refurbishment  of 
the  facility  were  a dedicated  group  and  long  hours  became  commonplace  as  the  seaside  environment  had 
taken  its  toll  on  the  unused  hardware.  It  took  two  years  to  complete  the  site  activation  work. 

There  were  more  major  modifications  than  expected  to  accommodate  the  Shuttle's  loading  requirements 
and  procedures  from  the  previous  program  were  scrapped  entirely  by  both  the  modifications  and  a new 
style  of  procedural  writing.  The  end  result  of  the  refurbishment  was  a staff  of  systems  engineers 
specialized  in  the  operation  of  the  hardware  and  ready  to  move  into  the  operational  phase. 

It  was  soon  obvious  that  the  job  of  system  engineering  would  have  to  expand.  Interfaces  with 
the  local  facility  contractors  and  the  NASA  design  group  were  suddenly  expanded  to  the  designers  of 
the  flight  hardware,  along  with  their  respective  NASA  counterparts  located  in  Houston,  Huntsville  and 
Kennedy  Space  Center.  Cryogenic  engineering  was  increased  to  include  the  related  engineering  fields 
of  mechanical,  electrical,  pneumatic,  and  thermal  as  the  decision  was  made  for  one  console  to  have 
loading  responsibility.  Routine  operations  were  being  moved  to  the  Firing  Room  consoles  to  take 
advantage  of  the  new  Launch  Processing  System  (LPS)  for  daily  tests  which  used  to  be  run  locally 
using  switches.  And,  most  significantly,  a complex  software  set  designed  to  use  LPS  for  all  opera- 
tions was  provided  to  the  systems  man  as  his  primary  'tool'  for  future  work. 

These  new  areas  of  responsibility  triggered  a new  definition  of  systems  engineer.  The  resulting 
months  of  preparation  for  the  STS-1  launch  were  spent  exercising  the  software  set  against  a high 
f i deity  math  model,  using  a simulated  loading  environment  to  establish  the  appropriate  man-to-machine 
interface.  The  support  of  a new  breed  of  software  engineers  was  needed  to  develop,  test,  and  demon- 
strate the  new  tool's  capabilities  and  limitations  to  the  systems  engineer.  Training  under  fire  for 
a chosen  few  seemed  to  be  the  only  method  timely  enough  to  safely  satisfy  the  major  objectives  of  a 
LOX  cold  flow,  tanking  test,  engine  firing,  TPS  retest  load  and  the  first  launch.  In  subsequent 
launch  flows,  this  broadened  definition  of  a system  engineer  continued  to  increase  as  the  mechan- 
ically and  hydraulically  operated  GOX  arm  was  added  to  the  LOX  console,  along  with  the  responsi- 
bility for  a purge  panels  on  the  mobile  launchers,  and  a new  understanding  of  geysers  with  the  re- 
moval of  the  ET  anti -geyser  line. 
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Training  continued,  in  parallel  with  the  launch  activities,  to  bring  the  new  assignments  of  the 
LOX  engineer  to  a clear  cut  definition  and  to  expand  the  talents  and  experience  of  the  entire  group. 
This  did  not  happen  easily.  Software  engineers  had  a different  perspective  on  what  was  efficient 
than  did  a field  engineer  and  quite  often  the  two  differed  as  to  how  the  tool  was  to  be  used.  Some 
systems  engineers  likened  the  Firing  Room  CRT  to  a glorified  video  game  and  perferred  to  do  only  the 
original  tasks  first  defined  as  system  work.  A third  generation  of  system  engineer  developed  - the 
console  operator,  a combination  of  both  the  software  and  the  hardware  expertise. 

These  are  the  words  this  author  has  used  to  answer  the  question,  "What  does  a systems  engineer 
do?"  This  paper  will  answer  the  question,  "What  is  the  system  engineer's  tool?"  In  order  to  avoid 
confusion,  the  liquid  oxygen  (LOX)  system  at  Kennedy  Space  Center  will  serve  as  the  example  cryogenic 
system.  Actually  the  Liquid  Hydrogen  system  was  developed  in  a similar  manner  and  contains  many  of 
the  same  philosophies.  The  lessons  learned  in  the  development  of  this  automatic  software  set  will  be 
discussed  in  three  phases  - design  and  debug,  verification  against  a mathematical  model,  and  modifica- 
tions due  to  hardware  testing.  This  includes  the  first  five  developmental  flights  of  the  Space  Shut- 
tle. Then,  a fourth  phase,  dealing  with  present  and  future  modifications,  will  be  discussed.  Each 
of  these  phases  will  present  several  examples  of  problems  which  were  solved  by  meeting  the  require- 
ments and  constraints  of  the  LPS  system  and  the  hardware.  Each  item  was,  in  itself,  a discovery, 
since  no  one  had  previously  used  a computer  to  control  the  LOX  system. 


DESIGN  AND  DEBUG  OF  LOX  SOFTWARE  SET 

The  original  LPS  system  was  designed  with  the  LOX  and  LHo  systems  in  mind.  NASA  felt  that  these 
two  systems  were  the  most  hazardous  and  complicated  and  therefore  would  serve  as  the  pilot  system  for 
the  general  architecture  of  an  automatic  software  set.  The  design  contractor  was  selected  to  do  the 
task  and  began  creating  the  structure  in  1976. 

The  LPS  system  restricted  the  use  of  a Firing  Room  console  minicomputer  to  3 CRTS,  3 keyboards, 

6 concurrent  programs  and  4 sub-calling  levels  for  an  application  program.  A brand  new  language  was 
devised,  GOAL,  which  was  close  enough  to  English  that  an  engineer  without  a software  background  was 
supposed  to  be  capable  of  reading  and  understanding  the  programs.  A Contnon  Data  Buffer,  several 
Front  End  Processors  and  Hardware  Interface  Modules  connected  the  LPS  system  to  the  hardware.  NASA 
asked  that  a modular  programming  concept  be  used  to  reduce  maintenance  and  increase  reliability  and 
further  restricted  the  number  of  concurrent  programs  to  two,  so  that  up  to  three  systems  could  be 
loaded  into  one  console.  It  did  not  take  very  long  to  adopt  a concept  whereby  all  monitoring  takes 
place  in  one  concurrency  and  all  control  and  decision-making  takes  place  in  the  other. 

In  the  monitor  concurrency,  an  overall  system  display  was  developed  using  the  proto-type  LPS 
character  set  which  provided  symbols  for  valves,  pipes,  transducers,  controllers,  wires,  switches  and 
various  components  which  could  easily  be  recognized  on  a 7x9  dot  matrix  character  and  could  occupy 
any  position  on  a 34  line-by-73  column  CRT.  This  overall  page  was  to  include  any  item  which  was  es- 
sential to  the  loading  operation  and  eventually  depicted  all  lines  in  the  Ground  Support  Equipment 
(GSE),  Mobile  Launcher  Platform  (MLP),  Fixed  Service  Structure  (FSS),  Tail  Service  Mast  (TSM), 

Orbiter,  Main  Engines  (SSME)  and  External  Tank  (ET)  which  were  subject  to  cryogenic  fluids  (see  Fig- 
ure 1).  Gaseous  purges  and  other  support  functions  were  left  off  the  overall  and  were  added  to  other 
displays  which  were  divided  into  the  three  areas  of  the  system  - storage  area,  MLP,  FSS/ET  (see  Fig- 
ure 2-4).  Also  during  the  debug  phase,  a fifth  display  was  added,  power  distribution,  to  complete 
the  original  display  set  (see  Figure  5).  All  of  these  displays  were  called  as  a sub-level  program  by 
a display  scheduler  which  tied  up  one  entire  concurrency.  The  schedular  is  seldom  executing  as  its 
main  function  is  a switcher  between  the  other  displays,  but  it  is  always  active  as  a top-level  pro- 
gram. The  LPS  system  allows  this  display  concurrency  to  be  seen  on  any  of  the  three  CRTs  at  the  LOX 
console,  but  only  one  display  can  be  seen  at  any  one  time  by  any  position.  This  did  not  seem  to  be 
a problem  at  the  time  since  only  one  operator  in  a loading  configuration  would  normally  be  watching 
the  display  and  his  interests  would  be  on  the  overall  display  most  of  the  time. 

An  entire  paper  could  be  written  on  the  human  engineering  involved  in  these  displays.  Many 
hours  were  spent  looking  at  all  facets  of  update  rate,  color,  size,  location,  identification, 
familiarization,  and  standardization  of  each  character  on  the  display.  These  displays  are  one  half 
of  the  man-to-machine  interface  and,  as  such,  take  on  a critical  role  in  an  automatic  control  system 
because  this  is  the  only  way  to  see  if  the  operation  is  proceeding  as  planned.  Virtually  80%  of  the 
operating  procedure  is  devoted  to  describing  exactly  what  the  operator  should  see  happening  on  the 
displays. 

One  other  important  feature  was  baselined  in  the  displays  to  increase  reliability  and  speed  in 
the  daily  operations  and  to  give  operator  flexibility  in  loading  operations  - cursor  control.  This 
allowed  an  operator,  using  the  display  page,  to  command  a valve  open  or  to  adjust  a pump  setting  sim- 
ply by  moving  the  console  cursor  (X-Y  type)  to  the  component  and  executing  a single  command.  In  real- 
ity, the  command  was  not  sent  from  the  display  concurrency,  but  from  the  control  concurrency.  A sim- 
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pie  communications  interrupt  and  parameter  passing  scheme  allowed  the  control  concurrency  to  be  mas- 
ter of  all  commands  whether  they  be  issued  from  the  automatic  software  or  from  an  operator  input. 

This  allowed  the  display  to  continue  updating  all  components  rather  than  dedicating  a fixed  amount  of 
time  during  the  commanded  valve  travel. 


Over  in  the  control  concurrency,  the  actual  commands  to  the  end  item  were  issued  by  a component 
program.  This  is  one  of  five  types  of  programs  in  the  control  concurrency  structure,  defined  as 
fol lows : 


Schedular 

Sequencer 

Component  programs 

Task  programs 
Interrupt  programs 


Allows  Operator  to  select  the  desired  test  he  wants  to  perform. 

Controlling  program  for  a particular  test.  Calls  lower  level  programs  in  proper 
sequence. 

Called  by  sequencer  to  perform  a particular  function,  i.e.,  open  a valve,  close 
a valve,  purge  on,  purge  off,  power  on,  power  off. 

Usually  called  by  sequencer  to  perform  software  chores  or  special  functions. 

Called  by  sequence  when  a measurement  deviates  from  a pre-determined  state  or 
value.  Provides  message  on  CRT  regarding  faulty  measurement  and  status  of  other 
measurements  pertinent  to  that  component. 


The  calling  heirarchy  of  these  programs  is  shown  in  Figure  6.  Calling  is  done  automatically  by 
the  sequencers  for  any  lower  level  program,  whereas  calling  for  a sequencer  is  done  manually  by  the 
operator  through  a Programmable  Function  Panel  (PFP).  This  panel  is  located  immediately  below  the 
CRT  and  provides  six  arm-and-fire  buttons  which  are  LED-labeled  to  prevent  operator  error.  The  PFP 
options  are  updated  by  the  manual  standby  sequencer  in  the  manner  shown  in  Figure  7.  Note  that  two 
actions  are  required  to  select  a sequencer.  This  is  now  a NASA  standard  for  all  systems. 
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Although  component  programs  are  most  directly  responsible  for  the  command/response  or  an  individ- 
ual end  item,  it  is  the  sequencers  which  perform  the  most  critical  functions  of  timing,  sequencing, 
safing,  and  redundant  operations.  The  four  sequencers  used  during  a loading  operation  are  fill, 
replenish,  drain,  and  revert.  These  four  programs  control  and  set  automatic  monitoring  for  the  more 
than  twenty  different  configurations  which  are  defined  in  the  LOX  Load/Drain  criteria  document. 

The  need  for  each  program  to  know  the  current  phase  of  the  system  gave  rise  to  global  flags  in 
the  data  bank.  These  came  to  be  known  as  pseudo-function  designators  (FD)  and  could  be  read  univer- 
sally throughout  the  Firing  Room  so  that  other  systems  (e.g.,  LHo,  Integration)  could  also  find  the 
necessary  information  about  the  LOX  system  status  without  disturbing  the  operators.  This  same  type 
of  pseudo-FD  was  used  for  flagging  failed  measurements  or  commands  (bypasses),  for  sending  communica- 
tion interrupts  from  console-to-console,  for  creating  duplicate  measurements,  and  for  communicating 
with  the  control  logic  (described  later)  programs  resident  in  the  console. 

All  together,  pseudo  discretes  (500)  and  pseudo  analogs  (2)  play  an  important  part  in  automatic 
software  communication.  As  evidence  of  the  necessity  of  these  pseudos,  NASA  now  reports  weekly  on  the 
limited  remaining  spares  and  as  every  other  system  increases  automation,  LO2  system  pseudos  have  ac- 
tually gone  down. 

The  fourth  important  piece  of  the  LOX  automatic  software  structure  is  a group  of  GOAL-like  pro- 
grams called  control  logic.  These  programs  reside  in  the  console  on  a high  speed,  high  priority 
basis  to  act  as  a double-check  that  no  command  is  issued  from  the  console  nor  does  any  primary  condi- 
tion exist  in  the  hardware  that  would  cause  an  immediately  hazardous  situation.  These  two  distinctly 
different  types  are  called  prerequisite  and  reactive  control  logic  respectively.  Prerequisite  con- 
trol logic  is  seldom  violated,  although  always  active,  in  an  automatic  system  since  the  sequencers 
activities  are  preplanned  and  have  been  tested  many  times  before  hardware  use.  Its  primary  function 
is  then  to  prevent  the  operator  from  manually  commanding  an  incorrect  action.  Reactive  sequences  are 
the  backbone  of  automatic  safing,  usually  sending  an  initial  salvo  of  commands  within  50  milliseconds 
and  then  triggering  a safing  sequencer  to  bring  the  system  to  a totally  secure  configuration. 

This  software  set  totaled  202  programs  with  over  64,000  lines  of  code.  The  majority  of  this 
code  was  written  within  the  timespan  of  one  year.  Obviously,  the  job  of  debugging  was  considerable. 
Some  help  was  gained  in  the  fact  that  these  same  concepts  were  used  in  the  liquid  hydrogen  automatic 
software  set  and  had  been  tested  against  a Math  Model  simulator  in  the  Firing  Room.  Debug  became  lit- 
tle more  than  a successful  compile  and  load  as  the  schedule  drove  into  the  next  phase  of  verifica- 
tion. The  classic  definition  of  debug  was  not  complete  and  as  such  debug  continued  long  into  the  ver- 
ification process.  However,  the  basic  structure  described  so  far  still  exists  as  the  structure  stan- 
dard for  today's  LOX  operations  as  well  as  the  standard  for  several  other  high  energy  systems  as  the 
automation  process  at  Kennedy  Space  Center  continues. 


VERIFICATION  USING  A MATHEMATICAL  MODEL 


This  phase  of  the  LOX  software  development  lasted  almost  three  years  as  engineers  struggled 
against  an  ever-changing  maze  of  LPS  system  software,  LOX  system  hardware  and  requirements,  and  a 
sliding  launch  schedule.  Engine  and  TPS  development  problems  which  slowed  the  entire  Shuttle  program 
made  it  difficult  to  predict  when  this  new  set  first  would  be  used  against  the  hardware.  Firing  Room 
time  was  hard  to  get  as  everyone  wanted  to  checkout  the  new  LPS  capabilities.  Manpower  was  limited, 
at  first,  because  the  complications  of  an  automated  control  system  required  software  engineers  to  aid 
systems  engineers  in  creating  the  automatic  set. 

Despite  these  complications  a great  deal  was  accomplished  during  this  phase.  The  greatest 
'aid'  of  all,  the  SGOS  Math  Model,  was  in  the  final  stages  of  development  and  provided  a high- 
fidelity  simulator  to  respond  to  the  application  set.  This  high-fidelity  modeling  is  essential 
to  the  verification  of  any  hazardous  software  set.  A great  deal  of  timing  problems  was  found 
simply  because  some  commands  responsed  in  milliseconds  and  others  would  see  no  appreciable  change 
for  up  to  one  minute.  Operator  training  became  important  and  if  a perspective  operator  watched 
the  model  respond  incorrectly  to  a given  situation,  it  would  be  sheer  guesswork  to  estimate  the 
effect  of  an  incorrect  real-time  reaction.  Details  of  the  LOX  model  will  not  be  discussed  in 
this  paper,  but  can  be  found  in  "Mathematical  Models  For  Space  Shuttle  Ground  Systems"  by  E.  G. 

Tory. 

The  second  major  accomplishment  of  this  phase  was  the  establishment  of  software  verification 
procedures  (SVP).  This  was  a configuration  - controlled  document  which  listed  the  exact  steps 
required  by  an  engineer  to  effectively  test  every  line  of  code  against  the  Math  Model.  Both  NASA  and 
contractor  management  could  not  justify  the  risk  of  leaving  out  unlikely  branches  of  code  from  the 
verification,  so  rather  than  accepting  an  improbable  failure,  a 12-volume,  7,000-page  set  of  SVPs  was 
developed  and  executed.  This,  of  course,  required  numerous  informal  runs  before  running  the  official 
test  with  the  signature  authorities  present.  To  this  day,  maintenance  of  the  SVP  is  a task  equal  to 
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the  effort  required  to  maintain  the  code.  Many  problems  were  found  as  the  SVP  sought  to  run  all  code 
over  and  over  again  in  different  configurations  to  really  provide  all  aspects  were  covered. 

The  third  major  accomplishment  was  the  development  and  use  of  simulated  loadings.  Over  thirty 
simloads  were  performed  before  the  first  Shuttle  tanking  test  at  KSC,  enough  to  try  over  100  differ- 
ent hardware  'failures'.  This  procedure,  with  over  twenty  different  operators  working  together  in 
the  same  Firing  Room  configuration,  using  the  same  consoles  and  communications  channels  as  a normal 
launch  day,  was  also  used  for  almost  1000  man-hours  of  informal  engineering  runs.  Once  again,  the 
Math  Model  proved  to  be  the  tool  capable  of  simulating  realistic  failures  or  anomalies,  and  then 
responding  to  the  workarounds  initiated  by  the  operator.  Many  a vehicle  was  "damaged"  as  the 
simloads  exercised  the  developing  software  set. 

The  verification  process  also  brought  some  significant  changes  to  the  actual  coding  design.  A 
new  flag  for  maintenance  operations  was  invented  as  a way  to  short-circuit  control  logic  which  was  al- 
ways active  but  was  designed  with  a loading  day  configuration  in  mind.  An  emergency  button  was  added 
to  the  PFP  that  could  call  a revert  and  bypass  all  control  logic  so  that  an  operator  would  have  total 
cursor  control  capability.  A hardwire  panel  was  added  to  the  console  to  provide  control  in  the  event 
of  a LPS  failure  and  a hardwire  recovery  sequencer  was  coded  to  provide  a faster  recovery  from  such 
an  event.  Every  component  program  was  rewritten  to  suspend  interrupt  processing  during  'valve  in 
transition'  when  the  first  valve  cycling  test  against  hardware  showed  two  interrupts  for  every  valve 
indicator  in  motion.  Measurement  sampling  rates  were  increased  from  1 sample  per  second  to  100  sps 
while  a valve  was  in  transition  and  then  returned  to  1 sps  so  that  accurate  data  was  automatically 
recorded. 

A significant  change  to  the  control  logic  design  had  to  be  found  when  ten  prerequisite  sequences 
exceeded  the  size  limitation  of  256  bytes.  The  coding  had  already  been  written  in  the  most  stream- 
lined fashion  so  the  only  alternative  seemed  to  be  a streamlining  of  the  requirements.  Deleting 
some  requirements  seemed  too  risky  since  control  logic  is  the  last  line  of  defense  and  the  impact 
to  the  LPS  to  upgrade  the  size  limitation  was  severe.  The  solution  seemed  to  be  to  find  a way  to 
consolidate  a block  of  'pump  off'  code  which  was  common  to  all  ten  prerequisite  sequences.  Since 
subroutines  were  not  possible  in  control  logic,  this  block  of  code  was  made  into  a reactive  control 
logic  sequence  which  was  always  active  and  whose  primary  function  was  simply  to  set  the  correct 
state  of  a 'pump  off'  pseudo  discrete  flag.  Now  the  ten  prerequisite  sequences  only  had  to  status 
the  one  flag  thus  reducing  all  the  programs  to  less  than  256  words.  This  became  known  as  a "pseudo 
reactive  sequence"  because  it  issues  no  commands  and  performs  no  safing  and,  as  such,  is  treated 
differently  than  all  other  reactive  control  logic  programs. 

Control  logic  also  provided  the  best  technique  for  a new  vent  valve  cycling  requirement  which 
came  into  effect  a few  months  before  the  first  launch.  Simply  stated,  the  ullage  pressure  in  the  Ex- 
ternal Tank  (ET)  must  be  maintained  above  1.7  psig  when  the  liquid  level  is  greater  than  2%.  A new 
set  of  two  low  pressure  measurements  with  a range  of  0-5  psig  were  installed  on  the  ET  along  with 
the  three  original  0-30  psig  high  range  instruments.  Since  this  requirement  applied  to  four  differ- 
ent sequencers  and  must  be  active  during  all  transitions  between  loading  and  drain  phases,  interrupt 
processing  alone  was  determined  to  be  risky  in  view  of  the  likelihood  of  tank  damage  as  a result  of 
a pressure  undershoot.  So  three  control  logic  programs  were  created  as  follows:  one  to  open  the 
vent  valve  on  the  high  limit  of  8.0  psig  based  on  any  of  the  high  range  transducers,  another  to  close 
the  vent  valve  when  the  primary  low  range  transducer  reached  2.2  psig  using  the  primary  command,  uid 
the  third  to  close  the  vent  if  the  secondary  low  range  transducer  reached  2.0  psig  using  the  second- 
ary command.  These  trigger  points  were  selected  to  allow  adequate  response  time  for  the  pneumatically 
operated  vent  valve  (2  seconds)  and  the  control  logic  sequence  (50  milliseconds).  This  concept  fea- 
tured a pair  of  totally  redundant  circuits  on  the  low  side  which  precluded  any  single-point  failure 
from  threatening  vehicle  damage.  Math  model  testing,  SVP,  and  simloads  were  used  to  verify  the  proc- 
ess and  the  decision  was  made  to  use  this  technique  for  the  first  loading  with  no  other  hardware 
testing . 


MODIFICATIONS  DUE  TO  FIRST  FIVE  LAUNCHES 


The  L0X  loading  for  the  first  space  Shuttle  launch  on  April  12,  1981  went  extremely  well.  This 
turned  out  to  be  the  sixth  loading  that  would  be  performed  using  the  baseline  STS-1  software  set  as 
a launch  scrub  and  two  TPS  tanking  tests  were  added  to  the  planned  loadings.  These  loadings  were  far 
from  'automatic'  though  as  operators  learned  to  manually  adjust  their  new  tool  to  the  first-time 
anomalies  as  they  occurred. 

The  two  biggest  problems  were  two  long-term  control  loops  which  had  to  be  done  manually  and  in 
parallel  by  the  same  operator.  The  nose  cone  purge  was  designed  for  a hardware  controller  to  maintain 
55  to  110  degrees  in  the  nose  cap,  but  failed  to  respond  fast  enough  to  the  cooling  effects  of  the 
vent  valve  cycling.  This  required  the  operator  to  manually  adjust  both  the  set  point  and  the  heater 
panel  output  temperature  and  to  constantly  monitor  for  further  adjustments  throughout  the  six  hour 
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countdown.  Also,  the  replenish  control  loop  coded  into  the  software  failed  to  achieve  the  stabilized 
values  which  had  been  seen  during  testing  at  the  National  Space  Technology  Laboratories.  So  the  same 
operator  for  the  final  three  hours  of  the  countdown  had  to  manually  monitor  and  adjust  the  replenish 
valve  to  maintain  a steady  flight  mass  on-board. 

The  other  operator  was  constantly  occupied  with  the  steady  stream  of  interrupts,  exception 
monitoring  and  anomaly  messages  generated  as  a result  of  several  blueline  measurements  being  set  too 
tight  to  allow  momentary  spikes  or  glitches  to  pass  through  the  wary  eye  of  the  computer.  Limit  set- 
ting during  debug  and  verification  had  not  seen  the  kind  of  'noise'  and  transducer  inaccuracies  which 
were  within  specifications  and  acceptable  for  a loading  environment. 

Other  annoyances  came  from  the  slower  than  expected  update  rate  of  the  displays.  It  took  fif- 
teen seconds  for  an  initialization  each  time  the  operator  changed  pages  and  then  ten  seconds  for  each 
subsequent  pass  through  the  loop.  Some  measurements  unexpectedly,  needed  to  be  constantly  monitored 
such  as  the  nose  cone  temperatures  and  the  pump  bearing  temperatures,  but  were  not  available  on  the 
overall  display.  When  the  operator  switched  to  a detailed  area,  say  the  storage  area  to  check  a pump 
reading,  there  was  a total  loss  of  visibility  to  the  rest  of  the  entire  system.  Application  programs 
had  no  way  of  knowing  when  control  logic  programs  had  interceded,  forcing  the  operator  to  presume 
that  his  invisible  safeguard  was  in  operation.  Communications  between  LOX  automatic  software  and 
Ground  Launch  Sequencer  (GLS)  automatic  software  were  operational  for  a normal  countdown,  but  incom- 
plete as  far  as  handling  some  abort  and  recycle  conditions.  Interfaces  with  GOX  arm  and  ET  power  oper- 
ators cluttered  the  communications  net  and  seemed  to  indicate  a need  for  greater  software  automation 
in  those  areas. 

Most  of  these  items  were  corrected  by  the  STS-2  launch  in  November,  1981,  however  two  major  pro- 
jects were  put  in  motion  on  the  second  software  set  which  would  take  until  the  last  developmental 
flight  (STS-5)  to  complete.  Several  years  had  passed  since  the  original  displays  were  built  and  the 
addition  of  new  items  late  in  the  development  left  some  areas  terribly  crowded  and  other  areas  to- 
tally blank.  Display  and  color  standards  had  been  adopted  by  NASA,  but  had  been  waived  to  avoid 
impacting  existing  displays,  so  there  were  several  obvious  items  of  non-conformance.  Update  rates, 
limited  visibility,  and  the  status  of  related  systems  became  a concern  as  described  in  the  previous 
paragraph.  All  these  became  of  more  concern  when  the  decision  was  made  to  move  the  GOX  arm  system 
into  the  LOX  console  and  to  absorb  their  software  and  displays.  Clearly,  a new  display  structure  was 
needed.  Secondly,  a top  level  decision  to  remove  the  LOX  anti-geyser  line,  as  a weight-saving  meas- 
ure, created  a much  tighter  set  of  temperature  requirements  in  all  phases  and  meant  a totally  new 
loading  procedure. 

Returning  first  to  the  display  problems,  it  seemed  certain  that  the  learning  experience  of  the 
first  six  loadings  should  allow  the  console  operators  to  redesign  the  overall  layout  so  that  it  could 
be  made  more  compact.  If  this  was  done  so  as  to  create  enough  room  to  have  a breakdown  area  included 
in  a split-screen  effect,  then  each  area  could  be  seen  without  loss  of  visibility  to  the  overall  and 
redundant  displaying  of  items  on  more  than  one  screen  would  be  unnecessary.  Pursuing  this  path  soon 
led  to  a single  display  with  three  sections  - the  top  half  was  the  overall,  the  bottom  right  quadrant 
was  the  GOX  arm  system,  and  the  bottom  left  quadrant  was  a selectable  area  which  could  show  either 
the  storage  area,  MLP,  FSS,  Power,  or  the  new  LPS  status  page  (see  Figure  8).  By  adding  In  the  new 
color  and  display  standards,  the  LOX  loading  displays  took  on  an  entire  new  look  on  the  outside,  but 
that  did  not  complete  the  job. 

On  the  inside,  a brand  new  structure  was  required  to  cyclically  update  the  selectable  quadrant 
as  a sub-level  program  from  the  overall,  rather  than  directly  from  the  schedular.  Voting  logic  from 
each  valve  with  multiple  indicators  and  bypasses  was  streamlined  to  be  unanimous  or  show  an  un- 
determined state  rather  than  projecting  a best  guess  to  the  operator.  Code  to  determine  signifi- 
cant change  from  the  previous  reading  on  analogs  was  dropped  as  bit  toggling  was  handled  by  a simple 
formatting  change.  Console  disk  files  were  used  as  an  innovative  method  for  saving  valve  states  while 
bouncing  between  displays.  Initialized  displays  stayed  in  an  undetermined  state  until  one  pass 
through  the  update  loop  to  prevent  the  operator  from  quickly  reporting  an  erroneous  state.  If  sev- 
eral measurements  could  be  interpreted  and  condensed  to  one  signal,  this  was  done  in  the  software  and 
shown  on  the  display  as  one  data  point.  New  coding  techniques  got  the  loop  update  rate  down  to  three 
seconds  and  initialization  time  down  to  three  seconds  on  sub-levels,  with  no  initialization  time  for 
the  overall  since  it  was  displayed  constantly.  This  entire  project  was  phased  in  over  three  loadings 
(STS-2  to  STS-4) , and  resulted  in  a total  achievement  of  the  previously  mentioned  objectives. 

During  the  same  loadings,  the  loading  criteria  was  rewritten  for  Orbiter  chilldown  and  slow  fill 
phases.  Test  data  from  STS-1  showed  sufficient  cooling  of  the  facility  to  allow  the  anti -geyser  line 
to  take  away  any  excess  heat  which  may  cause  a geyser  in  the  120-foot  long  17"  feedline  during  slow 
flowrates.  But  with  the  anti -geyser  line  removed  for  STS-5,  temperatures  were  several  degrees  above 
saturation.  At  first,  a 2-minute  hi-speed  flush  of  the  transfer  line  was  tried.  This  took  enough 
heat  out  of  the  facility  but  could  not  relieve  the  latent  heat  of  the  Orbiter  and  engines.  On  the 
next  loading,  the  flush  was  followed  by  a low  flow  load  to  the  engine  cut-off  sensors  (ECO)  with  a 
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5-minute  drain  back  through  the  engine  bleeds.  Each  loading  changed  the  valve  actions,  timers,  and 
redlines  such  that  the  same  software  was  never  used,  yet  each  time  the  automated  sequencer  had  the 
flexibility  to  safely  provide  the  required  LOX  on  time  to  support  launch  for  STS-5.  Several  modifica- 
tions had  to  be  made  to  the  terminal  count,  abort  and  recycle  operations  to  support  the  warmer  LOX 
coming  down  the  main  feedline  prior  to  engine  start.  Good  planning  and  the  conscientious  efforts  of 
the  entire  propulsion  community,  made  the  STS-5  tanking  test  and  the  subsequent  loading  for  launch 
the  first  truly  automatic  loadings  of  the  LOX  system  at  KSC.  All  of  the  procedures,  requirements, 
criteria,  software,  displays,  and  hardware  modifications  had  come  together  in  a way  as  to  allow  the 
auto  fill  sequencer  to  be  initiated  at  T-7  hours  and  automatically  continue  through  post-launch 
securing. 


THE  FUTURE  OF  AUTOMATIC  SOFTWARE 


The  future  of  automatic  software  is  now!  Based  largely  on  the  remarkable  success  of  the  LOX  and 
LH2  systems,  NASA  and  the  operations  contractors  have  formed  an  automation  sub-panel  which  has  estab- 
lished the  automation  goals  of  every  console  in  the  Firing  Room.  It  is  important  to  realize  that 
while  every  system  suffers  the  risk  and  effort  that  is  required  to  leap  from  a cursor-controlled, 
manually-operated  software  set  to  a fully  automated  one,  the  LOX  system  must  continue  to  improve. 
Software  decays ! It  becomes  outdated  as  the  world  of  hardware,  requirements  and  LPS  changes  around 
it. 


For  STS-6,  for  example,  a new  lightweight  ET,  a new  Orbiter,  and  a new  MLP  meant  the  operation 
of  configuration  flags  which  a single  sequencer  could  use  so  that  it  was  capable  of  loading  to  any 
configuration.  Representatives  from  Vandenberg  Air  Force  Base  are  part  of  the  automation  sub-panel 
and,  as  part  of  developing  their  LOX  software  set,  have  submitted  an  idea  for  parameter-passed  compo- 
nent programs  which  this  author  believes  will  save  maintenance  costs  over  the  life  of  the  Shuttle  pro- 
gram. LPS  is  scheduled  to  provide  more  coding  capabilities  which  will  allow  the  continued  develop- 
ment of  fault  isolation  and  correction  programs.  The  integration  console  is  designed  for  the  day 
when  a top-level  manager  program,  communicating  through  linkers  to  all  consoles,  can  kick-off  the  en- 
tire 72-hour  countdown  with  one  button. 
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Other  changes  to  software,  not  driven  by  improving  automation,  but  by  improved  hardware,  will  be 
required.  Already  approved  and  in  the  working  stages  are  a new  chilldown  sequence  for  STS-7,  a re- 
quirement to  delete  vent  valve  cycling  and  maintain  sub-cooled  LOX  for  STS-8,  an  increase  of  the  vent 
valve  stroke  limiter  to  1.5"  on  STS-10,  and  the  removal  of  the  2%  liquid  sensors  on  STS-13.  Eventu- 
ally there  will  be  two  launch  pads,  three  MLPs,  and  four  Orbiters  being  processed  in  parallel. 

Controlling  these  cryogenic  systems  and  other  hazardous  systems  must  be  accomplished  with  auto- 
mated software  for  the  Shuttle  program  to  meet  the  turnaround  time  objectives.  Systems  engineers 
will  continue  to  be  essential  to  perform  the  classic  functions  of  design,  test,  and  maintenance  of  the 
hardware  and  procedures,  but  we  must  also  take  an  active  part  in  design,  test,  and  maintenance  of  our 
most  valuable  tool  - the  software  set. 
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MATHEMATICAL  MODELS  FOR  SPACE  SHUTTLE  GROUND  SYSTEMS 


Edward  G.  Tory* 

Martin  Marietta  Corporation 
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ABSTRACT 


MATH  MODELS  are  a series  of  algorithms,  comprised  of  algebraic  equations  and  Boolean  Logic.  At 
Kennedy  Space  Center,  math  models  for  the  Space  Shuttle  Systems  are  performed  utilizing  the  Honeywell 
66/80  digital  computers,  Modcomp  11/45  Minicomputers  and  special  purpose  hardware  simulators  (Micro- 
computers). The  SGOS  (Shuttle  Ground  Operations  Simulator)  operating  system  provides  the  language 
formats,  subroutines,  queueing  schemes,  execution  modes  and  support  software  to  write,  maintain  and 
execute  the  models. 

Ground  systems  presented  here  consist  primarily  of  the  Liquid  Oxygen  (LO2)  and  Liquid  Hydrogen 
(LH2)  Cryogenic  Propellant  Systems,  as  well  as  LO2  External  Tank  (ET)  Gaseous  Oxygen  Vent  Hood/Arm 
and  the  Vehicle  Assembly  Building  (VAB)  High  Bay  Cells. 

The  purpose  of  math  modeling  is  to  simulate  the  ground  hardware  systems  and  to  provide  an  envi- 
ronment for  testing  in  a benign  mode.  This  capability  allows  the  engineers  to  check  out  application 
software  for  loading  and  launching  the  vehicle,  and  to  verify  the  Checkout,  Control,  & Monitor  Sub- 
system (CCMS)  within  the  Launch  Processing  System  (LPS).  It  is  also  used  to  train  operators  and  to 
predict  system  response  and  status  in  various  configurations  (normal  operations,  emergency  and  con- 
tingent operations),  including  untried  configurations  or  those  too  dangerous  to  try  under  real  con- 
ditions, i.e.,  failure  modes. 


The  Launch  Processing  System  (LPS)  at  KSC  consists  of  three  primary  subsystems:  The  Checkout, 
Control  and  Monitor  Subsystem  (CCMS),  the  Central  Data  Subsystem  (CDS),  and  the  Record  and  Playback 
Subsystem  (RPS),  (Figures  1 and  2). 

CDS  consists  of  four  large  Honeywell  66/80  Digital  Computers  (Systems  A,  B,  C and  D).  Systems 
A and  B are  designated  as  Set  1 and  C and  D as  Set  2.  Set  1 and  Set  2 are  identical. 

Within  a Set  the  systems  share  mass  storage  and  memory.  The  purpose  of  this  is  to  facilitate 
switchover.  Switchover  is  designed  so  the  primary  can  switch  to  the  secondary  in  case  of  a system 
failure  (only  during  launch  operations)  utilizing  the  Real  Time  Data  Management  System  (RTDMS). 

Each  system  has  dual  processors  and  each  processor  can  handle  1.2  million  instructions  per  sec- 
ond. Each  system  has  a mos  memory  of  1.5  million  (36  bit)  words  and  within  a Set  share  an  additional 
1 million  (36  bit)  words  of  memory.  Each  set  also  shares  64  disk  packs  containing  a total  of  over  12 
billion  (36  bit)  words  of  storage. 


Three  operational  modes  exist  for  SGOS  on  CDS:  (1)  Real-time,  (2)  Remote  Batch,  and  (3)  Remote 

Terminal . 

Real-time  mode  operates  with  any  of  the  three  Launch  Control  Center  Firing  Rooms.  FR-2  is  nor- 
mally configured  as  the  Ground  Software  Production  Facility  (GSPF),  where  model  performances  corre- 
spond to  actual  real  world  timing  of  events.  It  is  here  that  GOAL  Programs  are  de-bugged  and  veri- 
fied, and  engineering  evaluation  and  training  take  place. 

Remote  Batch  mode  is  initiated  from  a user's  remote  terminal.  There  is  no  interaction  between 
the  model  and  user  once  the  "job"  is  submitted,  and  processing  occurs  at  a much  faster  rate  than 
real-time  rate.  All  timing,  however,  is  relative  and  kept  consistent  with  real  world  activity.  For 
example,  in  filling  a tank  with  liquid  in  real  time  it  may  take  30  minutes,  but  in  Batch  Mode  this 
time  may  be  shortened  to  1 minute,  while  preserving  consistency  throughout  the  entire  model.  Output 
from  a Batch  run  can  be  printed  or  saved  in  mass  storage. 

(♦Senior  Field  Engineer,  MMC-KSC) 


INTRODUCTION 


LAUNCH  PROCESSING  SYSTEM  (LPS) 


SHUTTLE  GROUND  OPERATIONS  SIMULATOR  (SGOS) 
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Fig  1.-  Hardware  relationships  for  LPS/CCMS. 


ENGR.  AREAS 


Fig  2.-  CCMS/SGOS  relationships. 
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Remote  Terminal  Mode  (non-real  time)  is  used  for  creating  source  files  of  models,  procedures, 
and  data  banks.  Compilation  of  models  and  procedures  is  done  via  Terminal  Mode.  The  model  can  also 
be  executed  in  Terminal  Mode,  but  the  output  is  directed  back  to  the  user's  terminal,  where  an  inter- 
active session  can  occur. 

Engineering  Displays,  Full  Trace,  and  selected  Variable  Column  Trace  and  Plotting  are  available 
in  both  Terminal  and  Batch  modes. 

Real-time  also  supports  a logging  capability  similar  in  nature  to  the  non-real  time  Full  Trace, 
recording  every  change  that  occurs  within  the  model,  i.e.,  every  calculation  which  produces  a change 
in  value  or  external  stimuli  which  produces  a change. 


SYSTEMS  MODELED  AND  PURPOSE 


The  types  of  systems  involved  in  KSC  Ground  Math  Models  at  LC39  are: 

1.  Cryogenic  Fluid  Networks  (LO^  and  LH2) 

2.  Electrical  Power  Distribution  Systems 

3.  Mechanical  Devices,  GOX  Vent  Arm  and  Hood 

4.  Pneumatic  Actuators  and  Gaseous  Supply  Pressures  and  Purges 

Areas  Modeled  are: 

1.  Vehicle  Assembly  Building  (High  Bays) 

2.  Mobile  Launch  Platform  (MLP) 

3.  Pad  Terminal  Connection  Room  (PTCR) 

4.  Launch  Pad  39,  Storage  Areas  and  Burn  Pond 

An  End-to-End  Nodal  Analysis  is  necessary  for  modeling  the  cryogenic  fluid  networks,  therefore, 
the  LO2  and  LH?  External  Tank  and  Flow  Path  through  the  Orbiter  are  also  modeled  as  part  of  the 
Ground  System  Models. 

The  main  purpose  of  the  math  models  at  KSC  Is  the  checkout  and  verification  of  the  Ground  Opera- 
tions Aerospace  Language  (GOAL)  programs5  designed  to  automatically  load  and  launch  the  Space  Shut- 
tle. The  programs  must  control  and  respond  to  the  math  model  exactly  as  they  would  to  the  real  hard- 
ware. 


At  this  point  it  would  be  helpful  to  discuss  model  fidelity.  Model  fidelity  Is  the  degree  of  ac- 
curacy and  completeness  with  which  a model  simulates  the  real  world.  There  are,  then,  two  distinct 
model  forms,  namely:  imitators  and  predictors. 

An  imitator  is  a model  which  is  as  complete  as  it  must  be,  but  is  blind  to  any  other  conditions 
or  anomalies.  Coding  in  this  fashion  allows  for  computer  processor  efficiency,  faster-running 
models,  use  of  less  file  space,  and  easier  maintainability.  The  main  drawbacks  are  its  limited  scope 
and  flexibility.  An  imitator  is  based  mainly  upon  empirical  data. 

A predictor  is  a model  which  can  be  written  using  (in  addition  to  empirical  data)  real  physical 
equations  relating  flows,  pressures,  temperatures,  etc.  Coding  in  this  fashion  is  usually  more  diffi- 
cult, and  in  most  cases  requires  more  computer  time.  The  obvious  benefits  are  accuracy  and  flexibil- 
ity in  testing  new  operational  techniques,  and  accurate  predictions  of  system  response  in  abnormal 
and  failure  mode  configurations. 

As  it  turns  out,  KSC  models  are  a hybrid  of  these  two  forms,  stressing  predictive  qualities  in 
areas  of  fluid  networks  and  associated  calculated  phenomena,  and  an  imitative  analysis  in  areas  such 
as  electrical  power  and  pneumatics,  where  exact  replication  is  unnecessary. 
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MODELING  TECHNIQUES 


FLUID  NETWORKS 


FLows  and  Pressures 


Accurate  modeling  of  fluid  networks  has  proven  to  be  essential  for  cryogenic  propellant  loading. 
The  fluid  network  shown  in  Figure  3 is  for  LH2  and  LO2.  This  is  known  as  a nodal  analysis,  in  which 
a node  represents  an  exterior  source  or  sink  point,  and  interior  points  (points  at  which  there  is  a 
fluid  branch).  The  theory  behind  a nodal  analysis  is  conservation  of  mass,  or  continuity,  in  which 
the  sum  of  the  flows  into  an  interior  node  equals  the  sum  of  the  flows  out  of  that  node.  The  bound- 
ary conditions  must  be  known  or  calculated,  and  the  internal  admittance  between  nodes  must  also  be 
known  or  calculated.  A series  of  n simultaneous  equations  in  n unknowns  can  be  generated.  The  un- 
knowns we  are  solving  for  are  the  pressures  at  the  nodes.  The  flows  are  the  dependent  variables,  and 
once  the  pressures  are  solved  for  the  flows  are  calculated.  IN  SGOS,  the  "CALL  FLOW"  statement  pro- 
vides the  format  for  easily  setting  up  and  solving  any  fluid  network.  Specifically,  at  boundaries 
where  a source  or  sink  exist,  a pressure  must  be  input  at  that  node.  The  interior  admittances, 
called  G-numbers  or  Flow  Constants,  follow  the  inverse  rules  as  electrical  resistances  where  admit- 
tances in  series  sum  as: 

1/G2t  = 1/G2x  + 1/G22  + 1/G23  — + 1/G2n 


LH2 

EXTERNAL 

TANK 


LOX 

EXTERNAL 

TANK 
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and  admittances  in  parallel  sum  as: 

Gt  = Gi  + G2  + G3  + — Gn. 

However,  the  larger  the  value  of  the  G-Number,  the  greater  the  flow.  The  flow  constant  was  initially 
based  on  historical  data  and  design  information.  It  is  simply  a constant  that  is  a function  of  the 
Cv  of  the  valve,  the  density  of  the  fluid  flowing  through  it  and  admittance  of  the  plumbing  between 
nodes.  Originally  the  solution  for  flows  and  pressures  was  obtained  by  using  an  iterative  calcula- 
tion similar  in  nature  to  the  Runge-Kutta  method.  First  a nodal  analysis  of  the  network  is  drawn, 
then  the  pressures  at  the  ends  or  boundaries  are  calculated.  The  G-numbers  are  calculated  along  with 
the  head  pressures  between  the  internal  nodes.  Once  all  the  known  quantities  are  computed,  the  flow 
rates  are  calculated  using  the  flow  equation: 

Q = G^|  P2  - Pi  - HP2i 

where  Q = Flow  rate  in  gal/min 

G = Flow  constant 

?2  = Upstream  pressure 

Pi  = Downstream  pressure 

HP21  = Head  pressure  between  P2  and 

The  flows  are  iterated  to  increment  the  pressures  to  that  the  sum  of  the  flows  into  each  in- 
terior node  equals  the  sum  of  the  flows  out.  This  method  used  enormous  amounts  of  CPU  time  and  the 

accuracy  was  very  limited. 

SGOS  developed  the  "Call  Flow"  routine  in  the  Spring  of  1981.  This  new  method  of  computing 
flows  and  pressures  used  the  same  basic  flow  equation  and  nodal  analysis  as  before  as  well  as  the 
Law  of  Conservation  of  Mass. 

Given  boundary  conditions  of  known  pressures,  and  interior  G's  and  head  pressures,  solve 
(iterate)  for  the  pressures  at  the  interior  nodes  first  and  then  compute  the  flows.  The  method  of 
computing  these  interior  pressures  uses  a piecewise  linear  approximation  for  the  vector  square  root 
function.  Convergence  is  achieved  in  one  (50  millisecond)  model  cycle  as  opposed  to  hundreds  of 
cycles  before  which  at  best  only  approached  convergence. 

The  Flow  Solver  is  processed  in  the  SGOS  executive,  and  is  done  with  maximum  efficiency,  rather 
than  having  all  the  calculations  performed  in  the  model  itself.  The  ease  of  formatting  the  fluid  net- 
work and  the  reliable  accuracy  the  flow  solver  achieves,  has  made  true  predictors  out  of  the  LO2  and 
LH2  models. 

During  actual  vehicle  loadings.  Flows,  and  Pressures  were  recorded.  This  data  was  used  to  re- 
compute more  accurate  flow  constants,  which  then  reflected  all  the  dynamics  in  the  system.  Typical 

items  that  contribute  to  the  flow  constant  between  two  nodes  are:  valves,  orifices,  pipes  and  plumb- 

ing, filters,  and  the  fluid  medium  itself  (viscosity/density).  One  additional  consideration,  vitally 
important,  to  be  calculated  and  input  to  the  fluid  network  calculation  is  the  fluid  head  pressure. 

Head  Pressure  in  the  format  for  the  "CALL  FLOW"  is  input  as  a negative  number  when  computing 
Flow  from  a lower  elevation  to  a higher  elevation.  Knowledge  of  the  system  in  terms  of  elevations 
of  various  nodes  must  be  known,  as  well  as  the  volume  of  liquid  contained  in  various  segments  of  pipe 
between  nodes.  This  is  necessary  when  filling  or  draining  segments  of  pipe  to  allow  realistic  head 
pressure  rise  rates  as  the  pipe  fills  up.  When  flowing  "downhill"  head  pressure  is  added  to  the 
nodal  pressure,  and  will  increase  the  flow  rate.  When  flowing  "uphill"  the  head  pressure  is  added 
to  the  nodal  pressure  and  is  used  to  reduce  the  flow  rate. 


There  are  several  limitations  to  the  SGOS  CALL  FLOW  statement  which  can  be  treated  "outside"  of 
the  general  matrix  of  simultaneous  equations.  These  limitations  are:  fluid  inertia,  water  hammer, 

non-continuous  fluid  networks  (as  when  a segment  of  the  network  is  drained),  isolated  interior  net- 
works, check  valves  and  one-way  flow,  and  pumps  between  interior  nodes.  Detailed  discussion  of  these 
items  is  outside  the  scope  of  this  paper;  however,  these  problems  have  been  overcome  in  the  cryogenic 
models. 
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Volumes 


Volumes  of  tanks,  canisters,  and  pipes  are  needed  in  order  to  provide  a realistic  and  accurate 
model.  The  volume  of  liquid  in  a tank  at  a source  or  sink  node  is  computed  by  integrating,  using  a 
time  constant,  the  net  volume  that  exists  in  the  tank  - beginning  with  its  initial  volume  and  in- 
crementing by  adding  or  subtracting  the  flow  rate  from  that  node.  The  SGOS  "CALL  INTGRL"  statement 
is  very  useful  for  this  purpose.  "CALL  INTGRL"  provides  the  format  where  an  integrand  can  be  summed 
to  at  a fixed  but  selectable  rate  of  from  10  times  per  second  to  once  every  10  seconds.  A one  second 
update  is  normally  used,  but  a number  of  special  cases  need  faster  or  slower  iteration  rates. 

Volumes  of  pipes  between  nodes  can  be  computed  based  on  segment  length  and  diameter,  that  fill 
and  drain  based  on  flow  rates.  Imaginary  or  pseudo  wet/dry  liquid  sensors  at  each  node  triggers  the 
calculations. 


Temperatures 

In  most  instances,  temperature  dynamics  is  done  mostly  for  display  purposes.  A stagnant  or 
empty  segment  of  the  fluid  network  will  start  off  at  an  ambient  temperature  of  73°  F.  As  cryogenic 
fluid  enters  a segment  of  the  network,  rapid  boiling  occurs  and  gaseous  propellants  will  move  down- 
stream, causing  a pre-chi  1 1 down.  At  this  point,  we  start  calculating  temperatures  colder  until  ac- 
tual liquid  (based  on  tests)  would  reach  the  location  of  a temperature  probe.  When  the  liquid  volume 
reaches  a probe,  the  temperature  is  assumed  to  be  that  of  LO2  or  LH2  at  the  Boiling  Point.  Very  lit- 
tle change  in  temperature  will  occur  thereafter.  When  the  line  is  drained,  the  temperature  will  be- 
gin to  rise.  This  rate  may  be  rapid,  unless  the  line  is  vacuum-jacketed. 

One  notable  exception  where  temperature  fluctuations  are  pronounced,  dynamic  and  critical  is  the 
feedline  temperature  in  the  LO2  system,  which  forewarns  a geyser  condition  if  redline  criteria  are 
exceeded.  Due  to  head  pressure  in  the  feedline,  this  creates  a very  dynamic  temperature  profile  dur- 
ing loading. 


ELECTRICAL  SYSTEMS 

Power  supplies  are  usually  modeled  in  discrete  terms.  Power  is  either  on  or  off,  and  sub-busses 
automatically  receive  power  when  the  supply  is  turned  on.  Fuses  are  not  modeled,  but,  in  certain 
instances,  circuit  breakers  are.  Voltages  and  currents  are  assigned  as  constants  based  upon  hardware 
data.  These  systems  are  handled  rather  simply,  with  very  little  dynamics  involved.  Every  Function 
Designator  will  have  a power  bus  assigned  to  it,  and  when  the  power  is  off  that  "FD"  will  read  its 
powered-off  value.  Back-up  batteries  are  also  modeled,  along  with  a limited  amount  of  dynamics  in- 
volved with  threshold  Zener  Diode  Systems. 

PNEUMATIC,  GASEOUS  SUPPLIES  AND  PURGE  SYSTEMS 

Gaseous  supplies  are  treated  as  inexhaustable  reservoirs  which  supply  GNo  or  Helium.  Generally, 
these  supplies  are  for  purge  systems  and  pneumatically  actuated  values.  Modeling  of  these  systems 
typically  uses  discrete  logic,  depending  upon  whether  supply  valves  are  open  or  closed.  Dynamics  are 
involved  when  a regulator  is  modeled  using  the  line  pressure  as  a feedback  to  the  regulator  to  pro- 
vide more  or  less  regulator  opening.  Another  case  involving  dynamics  is  when  a purge  flows  through 
a heater  where  heater  temperature  is  a function  of  a cool  purge  flowing  through  it.  All  pneumatic 
values  are  modeled  to  require  a specified  minimum  supply  pressure  to  operate.  Helium  bubbling  in  the 
LO2  feedline  is  modeled  to  provide  a realistic  temperature  gradient  profile.  This  will  influence  the 
head  pressure  in  the  feedline. 

It  is  noteworthy  to  mention  that  for  the  LHo  system,  helium  is  always  used  when  cryogenic  hydro- 
gen may  be  present,  due  to  the  fact  that  the  boiling  point  of  helium  is  lower  than  that  of  LHo.  If 
GNo  were  used  in  contact  with  LH2,  the  nitrogen  would  form  GN2  ice.  In  the  LO2  system  both  GN2  and 
Helium  can  be  used  since  GN2  stays  gaseous  at  liquid  oxygen  temperatures.  For  economy,  GN2  is  gener- 
ally used  with  LC^. 


MECHANICAL  SYSTEMS 

The  ET  GO2  Vent  system  consists  of  a heated  purge  and  a hinged  cantilevered  truss  assembly  sup- 
porting a conical  shaped  plenum  chamber  (which  also  is  hinged).  It  is  moved  to  a docking  position 
with  the  ET  nose  cone  to  provide  an  environment  for  warming  the  nose  cone  while  venting  GOp,  which 
prevents  ice  build-up  on  the  ET.  The  simultaneous  motions  of  the  arm  and  hood,  primary  ana  secondary 
drives,  presented  an  interesting  challenge  in  designing  the  math  model. 
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MODEL  DEVELOPMENT 


DATA  COLLECTION:  FEEDBACK  TO  MODEL  THROUGH  STS-1 

Sources  for  model  data  include: 

1.  The  original  schematics  and  specifications 

2.  Discussions  with  engineers  about  operating  parameters 

3.  Consulting  with  vendors  on  specific  hardware  items,  and  actual  test  data  during  system  opera- 
tion. After  a hardware  test  (such  as  a tank  loading)  or  an  actual  launch,  a quantitative  analysis  is 
done  on  the  data  collected,  and  is  compared  to  model  output.  From  this  analysis  we  can  provide  accu- 
rate empirical  data  and  write  more  comprehensive  equations  for  further  model  development.  When  new 
operating  techniques  are  employed  during  a simulated  loading,  model  predictions  can  also  be  verified 
by  test  data  later. 


ADVANCED  DEVELOPMENT:  STS-2  THROUGH  STS-5 

Advanced  development  has  included  continual  feedback  from  hardware  testing  and  launch  data. 
Hardware  modifications  have  also  been  fairly  regular  throughout  each  flight,  and  model  dynamics  have 
been  heavily  impacted.  A "New  Standards  and  Guidelines  for  Math  Models"  (KSC-80K00009)  has  insti- 
tuted numerous  convention  and  fidelity  conformities.  This  was  necessary  in  order  to  coordinate  and 
make  common,  models  written  by  all  KSC  and  Vandenberg  Air  Force  Base  contractors.  This  has  also 
specified  the  identification  of  all  Ground  and  Vehicle  interfaces,  and  all  system  interfaces  to  be 
recorded  in  the  "Math  Model  Interface  Definition  Document"  (MMIDD). 


FUTURE  DEVELOPMENT:  STS-6  AND  BEYOND 

Model  enhancements  will  dominate  this  effort,  along  with  sustaining  engineering  for  hardware  mod- 
ification. The  most  significant  hardware  change  was  the  development  of  the  Martin  Marietta  Light 
Weight  External  Tank.  STS-6  was  launched  April  4,  1983,  with  the  first  lightweight  tank.  At  the 
time  of  this  writing,  STS-7  is  scheduled  for  launch  in  mid-June  and  will  have  successfully  completed 
its  mission  a week  before  this  conference. 

Future  plans  include  the  installation  of  a Centaur  stage  in  the  Orbiter  cargo  bay,  which  will  be 
fueled  with  LO2  and  LHo  simultaneously  with  the  External  Tank.  This  will  present  a new  challenge  for 
modeling  as  the  LO2  and  LH2  fluid  networks  will  be  modified  to  accommodate  this  space  vehicle.  At 
present,  the  first  Centaur  launch,  STS-38,  is  scheduled  for  May,  1986. 

Study  plans  are  under  way  at  Martin  Marietta  for  Shuttle  derived  vehicles.  Advanced  Space  Trans- 
portation System  (ASTS),  which  include  an  aft  cargo  carrier  (ACC)  or  shroud  on  the  External  Tank, 
with  a cargo  carrying  volume  greater  than  that  of  the  Orbiter  Cargo  Bay. 

Launch  Complex  39B  should  be  in  operation  by  January  1,  1986,  and  the  first  launch  will  be  STS- 
36,  in  February,  1986.  Pad-A  & B at  KSC  will  be  very  similar,  requiring  only  slight  model  changes. 
Mobile  Launch  Platforms  (MLP)  1 and  2 are  in  use  now  with  some  hardware  differences,  and  MLP-3  is 
being  processed  at  this  time. 

Vandenberg  models  were  patterned  after  KSC  models,  with  some  hardware  differences  inherent  to 
VAFB.  Their  first  launch  (IV)  is  scheduled  for  October,  1985.  Plans  are  for  KSC  to  operate  with 
0V99,  0V102  and  0V104  and  VAFB  to  operate  with  0V103. 

The  next  major  event  for  math  models  at  KSC  will  be  in  June,  1983,  with  the  implementation  of 
the  expanded  model  capability  project  also  known  as  BIG  SIM.  Currently,  the  largest  master  model 
which  can  be  built  is  approximately  227K  words.  It  may  be  possible  that  BIG  SIM  will  expand  that 
size  2 or  3 times.  This  new  capability  will  allow  for  an  integrated  test  of  a launch  countdown  model 
with  all  consoles  supporting.  Also  this  will  greatly  increase  GSPF  support  time  by  allowing  more 
users  to  operate  the  model  simultaneously  (restricted  only  by  the  processor's  capability).  This  will 
greatly  reduce  the  GSPF's  down  time,  because  at  present  each  of  several  smaller  master  models  must  be 
loaded,  which  can  take  several  hours,  during  which  time  there  is  no  model  support.  Once  a large  700K 
master  model  is  loaded  and  running,  it  can  support  continuously,  with  changes  necessary  only  to  up- 
date the  master  model.  Changes  will  not  be  necessary  for  scheduling  purposes. 
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With  the  large  master  models  it  will  be  necessary  to  streamline  all  existing  models,  to  write 
more  efficient  code,  and  to  understand  how  model  segments  are  ranked,  queued  and  executed.  Caution 
should  be  exercised  in  attempting  to  make  a model  segment  run  faster,  while  at  the  same  time,  not 
adding  more  of  a burden  to  the  model  executive  processing. 


CONCLUSION 

Math  modeling  presents  a unique  opportunity  to  intimately  blend  engineering/hardware  knowledge 
with  computer  technology.  Since  a model  must  perform  identically  as  the  hardware,  a very  broad  knowl- 
edge is  gained  by  the  modeler  in  both  the  hardware  and  the  software.  Within  the  environment  of  opera- 
tions and  maintenance,  this  author  has  found  model  research  and  development  to  be  challenging  and 
satisfying. 


In  closing,  I would  like  to  quote  from  Kenneth  P.  Timmons,  Michoud  Division  Vice  President  and 
General  Manager,  at  an  address  to  300  members  of  the  Louisiana  Tech  University  Engineers  Association 
in  Ruston,  Louisiana,  March,  1983: 

3"In  your  generation,  which  saw  polio  conquered  and  man  landing  on  the  Moon,  I believe  the 
greatest  advance  is  the  ability  to  model  events,  states  and  phenomena  and  to  process  these  models  in 
small  fractions  of  seconds  in  large  capacity  computers. 

Engineers  have  contributed  to  these  achievements  and  will  continue  to  make  us  part  of  the  techno- 
logical triumphs  - such  as  the  Space  Shuttle  - today." 
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ABSTRACT 


A detailed  discussion  of  Launch  Processing  System  (LPS)  Ground  Software  Production  is  presented 
to  establish  the  interrelationships  of  Firing  Room  resource  utilization,  configuration  control.  Sys- 
tem Build  operations,  and  Shuttle  Data  Bank  management. 

The  production  of  a Test  Configuration  Identifier  (TCID),  will  be  traced  from  requirement  genera- 
tion to  program  development,  Data  Bank  update,  GOAL  program  debug  and  verification  to  release  thru 
Configuration  Management  for  use  in  processing  flight  hardware. 

The  challenge  of  the  Operational  Era  will  be  to  implement  fully  automated  utilities  to  interface 
with  a CDS  resident  System  Build  Requirements  Document  to  eliminate  all  manual  intervention  in  the 
System  Build  operations.  Automatic  update/processing  of  Shuttle  Data  Tapes  will  enhance  operations 
during  multi-flow  processing. 


INTRODUCTION 


Ground  Software  Production  for  processing  and  Launch  of  the  Shuttle  Vehicle  begins  with  the  gen- 
eration of  requirements  for  a specific  mission.  The  changes  that  effect  ground  software  can  be  a 
hardware  modification,  flight  software  modification,  measurement  change,  or  a checkout  requirements 
change. 

Requirements  are  processed  through  the  Configuration  Control  Board  where  impacts  are  determined 
to  effect  OMI's,  application  software,  etc.  Based  on  approval,  updates  to  the  effected  elements  are 
scheduled.  Automated  tracking  systems  are  maintained  to  provide  visibility  of  open  work  items  to  sup- 
port software  planning,  scheduling,  and  engineering  open  item  reviews. 

These  automated  tracking  systems  are  the  cornerstone  of  an  automated  Configuration  Management 
(CM)  system  that  efficiently  tracks  software  requirements  from  identification  through  completion. 

The  CM  system  deletes  manual  intervention  by  interfacing  directly  with  the  System  Build  process.  The 
software  selects  the  approved  programs  and  console  locations  based  on  Vehicle  (099,  102,  103),  Site 
(OPF,  VAB,  PAD)  and  Facility  (MLP1,  MLP2,  HB1).  Additionally  the  CM  system  generates  a computer 
maintained  work  authorizing  document  for  Firing  Room  verification  supporting  real-time  Quality  Assur- 
ance buy-off,  automated  library  updates  and  Release  Notice  generation. 

The  System  Build  operation  utilizes  the  TCID  in  the  compilation  and  translation  of  all  applica- 
tion software  elements  into  a controlled  application  library  resident  on  the  Central  Data  Subsystem 
(CDS).  The  following  elements  are  included  in  a TCID:  (1)  Flight  Format  Files  (defines  valid  Pulse 

Code  Modulation  formats),  (2)  Function  Designator  Directory  (FDD)  Build  (selects  from  CCMS  on-line 
data  bank),  (3)  Front  End  Processor  Table  Build  (constructs  tables  from  FDD  and  Flight  Format  File 
data  describing  FEP  data  processing),  (4)  Application  Software  Configuration  (selects  application 
software  from  the  library,  updates  interpretative  code  from  the  FDD,  resolves  and  links  all  external 
references),  (5)  Installation  (collects  all  TCID  elements,  formats  data  for  CCMS  and  write  data  to 
CDS  tapes  for  tape  to  disk  generation  in  CCMS  or  real  time  CDS  to  CCMS  data  transfer)  (50KBS) . 

A Master  Math  Model  Build  is  also  performed  to  provide  simulation  capability  in  the  debug  and 
verification  process.  The  Master  Model  Build  selects  system  models  from  the  model  library  and  cre- 
ates simulation  tables  from  the  FDD.  These  models  interface  with  CDS  resident  simulation  software 
for  ground  software  development  activities. 

The  Software  debug  and  verification  process  is  performed  in  the  Ground  Software  Production  Facil- 
ity (Firing  Room  2).  Firing  Room  2 can  be  divided  into  three  sets  so  that  multiple  TCIDs  can  be  proc- 
essed concurrent >y.  The  three  sets  are  flexible  in  configuration  to  allow  a various  number  of  Consoles 
and  Front  End  Processors  to  be  used.  System  configuration  ties  the  Firing  Room  sets  to  simulation 
models  residing  in  the  CDS  computers  via  Video  Simulation  Interfaces. 

Following  software  verification.  Software  Assurance  and  Configuration  Management  provides  qual- 
ity control  verification  and  assures  compliance  with  all  effective  approved  engineering  requirements. 

"Manager,  Ground  Software/LPS  Operations,  RI-KSC 
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Additionally,  this  function  provides  verification  of  all  open  items  and  the  generation  of  Release  No- 
tices reflecting  the  configuration  of  application  software  packages  prior  to  the  package  being  used 
for  hardware  processing. 


SYSTEM  BUILD  OPERATIONS 


The  System  Build  function  is  the  compilation  and  translation  of  all  application  software  ele- 
ments into  a controlled  applications  library  resident  on  CDS.  An  Applications  TCID  can  be  divided 
into  the  following  categories  to  support  testing  and  Vehicle  processing:  (1)  Support  Equipment  Site 

Activation  and  Revalidation,  (2)  STS  Element  Test,  i.e.,  Orbiter,  SRB,  ET,  Cargo,  (3)  STS  Integrated 
Processing. 

Ground  software  types  included  in  a peculiar  TCID  include:  (1)  (GOAL)  Ground  Operations  Aero- 

space Language  programs,  (2)  Control  Logic  sequences,  prerequisite  and  reactive,  (3)  Display 
Skeletons,  and  (4)  Test  Control  Supervisor  sequences. 

Management  of  the  System  Build  process  is  controlled  by  the  System  Build  Manager  (SBM).  The  Sys- 
tem Build  Manager  is  a controlled,  interactive,  real-time  software  tool  for  initiating  and  executing 
all  TCID  build  functions.  The  SBM  software  was  generated  to  remove  manual  intervention  in  the  build 
process,  to  avoid  mistakes  and  to  create  a repetitive  process.  The  SBM  software  assures  that  (1)  The 
build  function  being  initiated  is  authorized,  (2)  Only  approved  application  program  revisions  are  in- 
cluded in  the  build,  (3)  Application  software  compiler  release  effectivity  is  correct  and  (4)  Applica- 
tion software  console  assignments  are  made.  The  SBM  generates  a log  for  historical  record  data  for 
inclusion  into  the  Software  Release  Notice. 

The  System  Build  process  is  controlled  by  Operating  Maintenance  Instruction  (OMI)  V 9025.  This 
OMI  is  broken  up  into  Mini  OMI's  for  individual  repetitive  execution  of  standalone  tasks.  It  defines 
Software  Assurance  check  points  and  minimizes  the  opportunity  for  human  error. 

This  System  Build  process  is  depicted  in  Figure  1. 
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To  meet  the  challenge  of  the  Operational  Era,  software  development  techniques  are  evolving  to 
allow  more  automated  utilities  to  control  the  System  Build  function  to  eliminate  errors  and  provide 
software  for  multi-flow  operations. 

A "System  Build  Requirements  Document"  concept  is  presently  ir,  development.  This  document  will 
contain  a complete  set  of  hardware  and  software  policies,  responsibilities,  configuration  and  inter- 
faces as  well  as  any  unique  support  requirements  for  each  Checkout  Control  and  Monitor  Subsystem 
(CCMS)  set. 

The  System  Build  Requirements  Document  will  consist  of  the  CCMS  data  which  will  control  the  LPS 
System  Build  process.  The  software  configuration  (Function  Designator  Directory  Build  requirements, 
table  build  requirements  and  application  software)  and  interfaces  will  be  stored  on  CDS  for  an 
Automated  TCID  Build  Process. 

Automated  utilities  will  be  developed  to  be  initiated  by  the  operator  for  access  to  the  System 
Build  Requirements  Document  on  CDS  to  produce  a Function  Designator  Directory  Build  input  deck,  a 
table  build  input  deck  and  a baseline  of  application  programs  to  support  that  TCID. 

The  intent  is  to  use  the  System  Build  Requirements  Document  to  control  the  LPS  System  Build  proc- 
ess from  start  to  finish  by  utilizing  this  Document  as  well  as  Automated  Software  Utilities  to  fully 
implement  an  approved  set  of  requirements.  This  concept  is  depicted  in  Figure  2. 


Figure  2.-  System  build  requirement  document. 


SHUTTLE  DATA  BANK  MANAGEMENT 


The  Shuttle  (CCMS)  Data  Bank  is  a large,  structured,  disk  file  residing  in  the  Central  Data 
Subsystem.  The  Data  Bank  contains  all  the  information  on  measurements,  stimuli,  and  system  parame- 
ters needed  for  the  operation  of  CCMS  support  software.  Among  other  data,  the  CCMS  Data  Bank  con- 
tains function  designator  data  for  each  measurement  and  stimulus  of  the  Shuttle  Vehicle.  The  func- 
tion designator  data  consists  of  the  Measurement/Stimulus  Identification  (MSID)  number,  name,  range, 
dimensional  units  and  other  such  characteristics. 
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The  CCMS  Data  Bank  is  maintained  in  three  sections  on  a common  disk  including  a section  for 
Space  Shuttle  Vehicle  (SSV),  for  Ground  Support  Equipment  (GSE),  and  one  for  Cargo/Payloads.  KSC  is 
the  design  agency  for  the  GSE  section.  JSC,  MSFC  and  Rockwel 1 /Downey  are  responsible  for  SSV  and 
Cargo/Payloads. 

The  use  of  function  designators  (FD)  is  a fundamental  GOAL  concept  that  allows/requires  the  GOAL 
Programmer  to  specifically  designate  the  function  and  destination  of  external  references.  Approxi- 
mately 50,000  FD's  reside  in  the  CCMS  Data  Bank,  broken  down  as  follows:  (1)  Orbiter  - 24,000,  (2) 

SSME  - 1400,  (3)  ET  - 500,  (4)  SRB  - 1100,  and  (5)  GSE  - 23,000.  Each  FD  requires  approximately  55 
pertinent  pieces  of  technical  data  for  a total  of  2.7  million  data  elements  for  a single  mission. 

A Shuttle  Data  Tape  (SDT)  supplies  the  measurement/stimulus  data  from  the  design  agencies  to  the 
LPS  for  the  generation  of  CCMS  Data  Bank  field  data. 

The  Shuttle  Data  Tape  Processor  is  a unique  software  component  that  forms  the  repository  of  Shut- 
tle information  required  in  the  CCMS  Data  Bank  under  control  of  the  CDS  Operating  System. 

From  the  raw  SDT,  the  Processor  generates  a file  of  card-image  updates  for  the  Shuttle  associated 
function  designator  in  the  CCMS  Data  Bank.  This  update  file,  along  with  other  required  data,  will  be 
used  to  update  the  CCMS  Data  Bank.  Typical  flow  of  SDT  to  Data  Bank  updating  process  is  shown  in 
Figure  3. 


Figure  3.-  Typical  SDT-to-DB  updating  process. 
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Data  Bank  Services  functions  are  utilized  to  add,  modify,  delete,  copy  transfer,  and  receive  the 
various  types  of  records  in  the  Data  Bank.  The  Data  Bank  Update  Generator  portion  of  the  SDT  Processor 
builds  compiler  and  hardware  records  according  to  data  link,  data  type  and  on-board  sources  and  desti- 
nation. These  records  are  compared  to  current  records  in  the  Data  Bank.  Following  these  comparisons, 
the  Data  Bank  Generator  provides  update  data  for  the  Data  Bank  reflecting  new  or  modified  data  fields 
from  the  SDT.  Data  Bank  update  change  approval  flow  is  shown  in  Figure  4. 
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Figure  4.-  CCMS  data  bank  update. 


FIRING  ROOM  UTILIZATION 


To  meet  the  challenge  of  the  Operational  Era,  efficient  utilization  of  Firing  Room  resources 
will  be  mandatory  to  manage  multi-flow  schedules.  Presently,  three  Firing  Rooms  are  available  at  KSC 
for  Vehicle  processing  and  software  development  activities.  Firing  Room  4 is  presently  under  con- 
struction. 

Firing  Room  2 at  KSC  has  been  designated  as  the  Ground  Software  Production  Facility  (GSPF).  The 
GSPF  has  been  divided  into  three  sets  for  maximum  resource  utilization  and  allowing  multiple  software 
TCIDs  to  be  processed  concurrently.  Reference  Figure  5 for  Software  Development  Configuration. 

The  three  sets  are  very  flexible  in  order  to  allow  a varying  number  of  Consoles  and  Front  End 
Processors  to  be  used.  The  configuration  ties  the  Firing  Room  sets  to  simulation  models  residing  in 
the  CDS  computers  via  "Video  Simulation"  interfaces.  Software  is  executed  from  the  consoles  with  re- 
sponses from  the  system  models  in  the  debug/verification  process.  The  system  models  are  controlled 
from  a console  in  the  CDS  set.  Verification  of  application  programs  are  performed  per  approved  Soft- 
ware Verification  Procedures  (SVP's). 

Software  planning  and  resource  utilization  control  is  managed  by  software  planning  and  utiliza- 
tion scheduling.  The  Software  Integrated  Support  Schedule  is  updated  weekly  and  shows  the  complete 
software  development  cycle  from  Data  Bank,  System  Build,  debug,  verification  and  release  to  hardware 
testing. 

The  STS/Payload  72  Hr/ll  Day  Operations  Integration  Schedule  is  updated  via  daily  meetings  to  re- 
flect the  Day  to  Day  schedule  and  set  utilization.  The  Software  Test  Conductor  who  coordinates  the 
GSPF  activity  has  the  authority  to  make  real  time  schedule  adjustments  to  meet  changing  real  time 
requirements. 
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Figure  5.-  Software  development  configuration. 


The  Software  Development/Release  process  through  the  Ground  Software  Production  Facility  is 
shown  in  Figure  6. 

Change  control,  use  of  automated  utilities  and  configuration  management  are  essential  keys  to  ef- 
ficient software  production  operations  to  meet  the  challenges  of  the  Operations  Era. 


« 
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Figure  6.-  S/W  development/release. 


564 


|g 8 5 -1693  5 


SUPPORT  SYSTEMS  DESIGN  AND  ANALYSIS 


Robert  M.  Ferguson* 
DL-NED-2 

NASA,  Kennedy  Space  Center 


ABSTRACT 

The  integration  of  KSC  ground  support  systems  with  the  new  Launch  Processing  System  and  new 
Launch  Vehicle  provided  KSC  with  a unique  challenge  in  system  design  and  analysis  for  STS.  Approxi- 
mately 70  support  systems  were  to  be  controlled  and  monitored  by  the  Launch  Processing  System.  Typi- 
cal systems  are  Main  Propulsion  Oxygen  and  Hydrogen  loading  systems.  Environmental  Control  Life  Sup- 
port system.  Hydraulics,  etc.  An  "End-to-End"  concept  of  documentation  and  analysis  was  chosen  and 
applied  to  these  systems. 

Unique  problems  were  resolved  in  the  areas  of  software  analysis,  safing  under  emergency  cond- 
itions, sampling  rates,  and  control  loop  analysis.  New  methods  of  performing  "End-to-End"  reliabil- 
ity analyses  were  implemented.  This  paper  discusses  the  systems  design  approach  selected  and  the  res- 
olution of  major  problem  areas. 


KSC  SYSTEMS  PROBLEM  IN  SHUTTLE  ACTIVATION 


The  integration  of  ground  support  systems  with  the  new  sophisticated  Launch  Processing  System 
(LPS)  presented  KSC  with  a unique  challenge  in  system  design  and  analysis  for  STS. 

It  was  the  intent  that  the  LPS  would  be  used  to  control  and  monitor  approximately  70  support 
systems.  An  applications  software  set  would  be  developed  for  each  system.  Examples  of  these  systems 
are:  Fuel  Cell  Servicing  System,  Hypergol  Loading  System,  Main  Propulsion  Oxygen  and  Hydrogen 

Loading  systems.  Environmental  Control  System,  Orbiter/SRB  (Solid  Rocket  Booster)  Hydraulics,  Environ- 
mental Control  Life  Support,  etc.  The  challenge  was  to  develop  methods  to  document,  define  software 
requirements,  and  assure  a "fail  safe"  design  for  these  systems. 

A system  usually  consists  of  many  components  which  have  been  designed  by  KSC  and  other  NASA 
Centers.  A multitude  of  different  design  disciplines  are  involved.  (See  Figure  1).  There  existed 
a need  to  tie  these  diverse  elements  together  in  a systematic  manner  to  define  an  end-to-end  system. 


THE  SYSTEM  DESIGN  APPROACH  SELECTED 


In  reviewing  existing  KSC  design,  documentation  and  reliability  analysis  procedures  at  the  time, 
it  became  apparent  that  new  and  innovative  approaches  were  needed  to  design,  document  and  analyze 
software  controlled  systems.  The  system  design  approach  was  to  bring  together  some  quality  engineer- 
ing talent  who  were  familiar  with  total  system  requirements  and  assign  them  the  job  to  integrate 
fluids,  electrical,  LPS,  controls,  and  sensor  designs  into  an  end-to-end  system  design.  The  design 
process  selected  is  shown  in  Figure  2.  Some  of  the  unique  elements  in  this  process  are  the  SMS/EMCD 
(System  Mechanical  Schematic/Electro-Mechanical  Control  Diagram),  and  the  Operating  Criteria.  The 
SMS/EMCD  (see  Figure  3)  was  developed  as  a new  drawing  to  aid  designers,  operators,  and  application 
software  programmers,  to  understand  a system  end-to-end.  The  SMS/EMCD  depicted  a system  from  the  GSE 
thru  the  Orbiter/SRB/ET  (External  Tank)  showing  those  elements  on  board  the  vehicle  that  function  as 
part  of  Ground  System  Operation.  In  addition,  the  SMS/EMCD  showed  all  commands  and  monitors  with 
their  function  designators  to  aid  the  system  software  programmers.  The  Operating  Criteria  explains 
the  step  by  step  operation  of  a system;  for  instance,  in  Main  Propulsion  Lox,  these  are  such  things 
as  set-ups,  chill  down,  slow  fill,  fast  fill,  topping,  and  replenish.  This  document  had  been  used 
previously  by  KSC,  but  it  was  expanded  to  provide  additional  information  for  the  software  programmer. 
As  an  example,  a section  was  added  to  satisfy  control  logic  software  interlocks.  The  intent  was  that 
with  the  SMS/EMCD,  Operating  Criteria,  and  Electrical  Schematic  systems  operating  personnel  would 
have  all  information  needed  to  develop  software  flow  diagrams,  and  code  the  application  software. 
Referring  to  Figure  2,  many  other  documents  are  needed,  but  the  key  documents  are  the  SMS/EMCD, 
Operating  Criteria,  and  Electrical  Schematic.  With  this  documentation  it  is  also  possible  to  provide 
an  end-to-end  system  assurance  analysis  which  will  be  addressed  later.  To  implement  the  system  design 
process  at  Kennedy,  System  Integration  teams  were  formed  consisting  of  designers,  operators,  safety, 
and  reliability  personnel.  The  teams  met  on  a regular  basis  to  review  and  assure  that  all  necessary 
requirements  were  incorporated  into  the  system  design. 


♦Chief,  Systems  Design  Branch 
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Figure  1.-  Typical  valve  control /monitor. 


SPECIAL  PROBLEMS 


Software  would  have  to  be  analyzed  to  satisfy  an  end-to-end  system  assurance  analysis.  The 
amount  of  software  and  changes  to  software  would  be  of  such  a tremendous  quantity  that  it  would  be  im 
possible  to  analyze  the  software  and  maintain  the  analysis  current.  To  circumvent  this  problem,  it 
was  decided  that  critical  interlocks  would  be  placed  in  the  control  logic  portion  of  the  application 
software  set  (See  Figure  4).  By  doing  this,  the  amount  of  software  to  be  analyzed  would  be  highly 
restricted,  making  it  practical  to  perform  a software  analysis.  The  objective  achieved  was  to  place 
GOAL  applications  programs  under  Operations  control  and  Control  Logic  programs  under  Design  control. 
Criterias  were  structured  so  that  each  system  control  logic  requirement  was  spelled  out.  To  analyze 
these  hazardous  situations  the  requirements  were  stated  in  the  Operating  Criteria  and  the  implement- 
ing software  was  written  in  control  logic,  making  it  relatively  easy  to  perform  a software  analysis. 

Emergency  Safing  took  on  a new  meaning  when  coupled  with  the  new  LPS.  While  the  LPS  was  de- 
signed to  have  a standby  console,  it  would  take  approximately  15  or  20  minutes  to  bring  the  redundant 
console  on  line  and,  if  a hazardous  propellant  loading  were  in  process  at  the  time,  the  vehicle 
could  be  left  in  a hazardous  condition  during  this  transition  to  another  console.  Another  exam- 
ple is  a failure  mode  in  the  LPS  common  data  buffer  which  stops  processing  of  all  LPS  information. 

To  circumvent  these  situations  and  others  of  this  nature,  an  emergency  hardwire  safing  system  was 
implemented.  This  system  bypasses  the  LPS  system  from  a control  panel  located  in  each  LPS  console 
which  is  used  to  place  the  system  in  a safe  condition  until  the  LPS  has  regained  control  (see 
Figure  5).  For  example,  in  Main  Propulsion  Lox,  if  an  LPS  failure  occurs,  the  integration  console  as 
sumes  the  safing  function;  if  the  integration  console  has  also  failed,  the  Emergency  Safing  system 
commands  the  pumps  to  stop,  opens  the  vehicle  vent  valves,  and  leaves  the  system  in  a safe  stand  by 
condition.  Further,  if  the  problem  were  of  an  extreme  nature,  the  Emergency  Safing  system  can  be 
used  to  drain  liquid  oxygen  and  liquid  hydrogen  from  the  vehicle.  Systems  other  than  MPS,  LOX  and 
LH2  (such  as  Hypergols,  Fuel  Cells,  etc.)  fail  to  the  Emergency  Safing  as  back-up.  Thru  STS-6  there 
has  been  only  one  usage  of  the  Emergency  Safing  System  which  attests  to  the  reliability  of  the  LPS. 
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Figure  2.-  DE  systems  design  process. 


Since  sample  rate  is  of  prime  importance  for  proper  utilization  of  a computer  control  system,  a 
basic  requirement  was  levied  on  designers  to  use  a sampling  rate  of  one  sample  per  second  for  all  com- 
mands and  monitors,  and  that  higher  sampling  rates  would  require  special  approval.  This  did  not  pre- 
clude that  during  an  operation  the  samping  rate  could  be  raised  at  the  time  a higher  sampling  rate 
was  required.  The  sizing  of  this  task  is  better  understood  by  the  fact  that  6500  commands  and  moni- 
tors are  used  in  the  launch  configuration. 

Analysis  was  performed  on  the  control  Loops  of  a higher  complexity  first;  and,  then  as  time 
allowed,  this  analysis  was  extended  to  less  complex  situations.  As  a result  of  control  loop  anal- 
ysis, problems  were  uncovered  on  propellant  replenish  and  hypergol  loading. 


RELIABILITY  ANALYSIS 


Previously  at  KSC,  reliability  analysis  had  been  performed  in  piece  parts.  There  was  a mechani- 
cal systems  analysis  for  the  Lox  system  and  an  electrical  systems  analysis  for  the  LOX  system.  In  ad- 
dition, there  was  a vehicle  analysis  for  the  Lox  system.  These  analyses  were  not  tied  together  end- 
to-end.  The  SMS/EMCD  was  made  to  depict  an  end-to-end  system  with  the  onboard  vehicle  components  that 
function  as  part  of  the  GSE  operations.  In  the  KSC  System  Assurance  Analysis  four  areas  (see  Figure 
6)  were  analyzed  to  assure  that  the  analysis  was  end-to-end:  These  areas  were: 

1)  The  KSC  GSE  system  (electrical/mechanical/electronic) . 

2)  The  control  logic  software. 

3)  The  LPS  CCMS  hardware  and  Executive  software. 
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4)  Other  Center  Analyses.  A review  was  made  of  the  analyses  provided  by  other  Centers  of  the 
on  board  vehicle  components.  When  problems  were  uncovered  in  analyses  from  other  Centers,  these  prob- 
lems were  presented  to  other  Centers  as  "Items  of  Concern".  Several  "Items  of  Concern"  were  identi- 
fied, due  to  the  fact  that  other  Centers  used  different  analyses  techniques,  and  that  their  analyses 
addressed  the  flight  configuration  instead  of  the  ground  servicing  configuration.  An  example  of  one 
of  these  Items  of  Concern  was  a failure  to  the  closed  position  of  the  LOX  Inboard  Fill  Valve  during 
GSE  loading  operations.  This  was  not  addressed  in  the  Orbiter  FMEA  (Failure  Mode  Effect  and  Analysis). 
This  failure  mode  was  classified  hazardous  as  a result. 
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The  Shuttle  program  offered  many  challenges  to  system  designers  at  KSC.  The  implementation  of 
the  LPS  for  control  contributed  to  the  expansion  of  the  system  design  function.  The  methods  that 
have  been  developed  as  being  refined  and  applied  to  such  current  programs  as  Centaur  and  the  nuclear 
power  control  field.  These  methods  have  produced  reliable  systems  for  STS  and  will  serve  well  in  the 
operations  era. 
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Figure  5.-  Emergency  saflng  system. 
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ABSTRACT 


Large  quantities  of  hazardous  cryogenic  propellants  are  loaded  aboard  the  Space  Shuttle  prior 
to  launch.  The  Hazardous  Gas  Detection  System  is  designed  to  detect  leaks  which  could  result 
in  pre-launch  or  in-flight  fires  or  explosions. 

This  paper  describes  the  historical  development,  design,  anJ  performance  of  the  HGDS.  Data  for 
response  time,  detection  limits,  accuracy,  and  drift  are  presented.  Finally,  present  and  future  ap- 
plications are  discussed,  and  some  general  conclusions  are  drawn. 


INTRODUCTION 


Over  1.5  million  pounds  of  liquid  oxygen  and  liquid  hydrogen  are  pumped  onto  the  Space  Shuttle 
during  final  countdown.  Leaks,  either  during  pre-flight  preparations,  or  in-flight  could  result  in 
a fire  or  explosion  which  would  endanger  the  Space  Shuttle  and  its  crew.  The  Hazardous  Gas  Detection 
System  (HGDS)  is  designed  to  detect  the  presence  and  measure  the  concentration  of  hazardous  gases 
within  the  Space  Shuttle. 

The  HGDS  is  located  inside  the  Mobile  Launch  Platform  and  consists  of  three  subsystems.  The  sam- 
ple delivery  subsystem  draws  samples  from  four  Space  Shuttle  compartments  surrounding  propellant  tanks 
and  engines,  and  provides  calibration  gas  samples.  These  compartments  are  the  External  Tank  Intertank 
Area,  the  Orbiter  Aft  Fuselage,  Payload  Bay,  and  Midbody.  All  are  purged  with  gaseous  nitrogen  during 
propellant  loading.  The  mass  spectrometer  measures  the  samples  from  these  areas  qualitatively  and 
quantitively  for  specific  compounds.  These  are  hydrogen,  oxygen,  helium,  argon,  and  up  to  four  others. 
The  control  and  data  subsystem  controls  the  entire  system,  and  provides  operator  interface  for  local 
setup  via  keypads  and  a display  panel.  Once  this  setup  is  complete,  control  is  transferred  to  the  Fir- 
ing Room  in  the  Launch  Control  Center.  All  measurement  and  control  during  propellant  loading  is 
handled  through  the  Launch  Processing  System.  The  Firing  Room  console  operator  controls  the  system 
and  warns  propellant  loading  and  test  management  personnel  of  leaks  which  might  endanger  the  Shuttle 
or  the  astronauts. 


HISTORY 

The  Hazardous  Gas  Detection  System  was  first  used  in  the  early  Saturn  program.  A need  to  detect 
leaks  in  the  Saturn  I Launch  Vehicle  was  recognized  in  1964.  The  first  HGDS  was  a modified  magnetic 
sector  residual  gas  analyzer.  It  was  brought  from  Huntsville  for  each  launch,  set  up,  and  operated 
by  a chemist  from  Marshall  Space  Flight  Center. * As  Figure  1 shows,  it  was  crude,  and  could  only 
measure  hydrogen,  but  it  demonstrated  the  potential  of  mass  spectrometry  as  applied  to  space  vehicle 
leak  detection. 

The  system  was  gradually  improved  until,  by  the  first  Saturn  V flight,  a stable  design  configura- 
tion was  reached.  A valve  manifold  was  added  to  allow  sampling  from  four  areas  and  from  a calibration 
gas  cylinder.  Packaging  was  improved  and  a peak  selector  was  added  to  allow  measurement  of  hydrogen, 
oxygen,  nitrogen,  helium,  and  argon. * The  Saturn  V configuration  is  shown  in  Figure  2. 

The  Saturn  HGDS  produced  reliable  data  throughout  the  program.  It  never  failed  to  operate  when 
needed;  however,  it  required  time  consuming  maintenance  and  calibration.  The  operator  interface  was 
anything  but  simple.  System  operation  was  slow,  requiring  eight  minutes  to  survey  the  entire  space 
vehicle.  For  the  Space  Shuttle  program,  a faster,  more  operator-friendly  system  was  needed,  while 
still  retaining  the  sensitivity  and  flexibility  of  a mass  spectrometer . 


SHUTTLE  HGDS  DESIGN 


A set  of  design  goals  was  established  to  guide  the  development  of  the  Shuttle  HGDS. 

- Fast  response  (2  minutes  to  survey  the  entire  Shuttle) 

- Accurate  (+/-5£  of  reading) 

- Automatic  calibration  and  operation 
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- Flexible,  to  meet  changing  requirements 

- Rugged,  to  meet  the  launch  vibration  environment 


Fig  1.-  Saturn  I HGDS.  Fig  2.-  Saturn  V HGDS. 


In  order  to  demonstrate  these  concepts,  a prototype  system  was  constructed  and  tested  by  the  De- 
sign Engineering  Directorate  at  Kennedy  Space  Center.  It  was  sent  in  1977  to  the  National  Space  Tech- 
nology Laboratories  in  Bay  St.  Louis,  MI,  for  Main  Propulsion  Test  Article  static  firings.  Experi- 
ence from  KSC  and  MPTA  testing  was  used  to  formulate  the  specifications  for  operational  systems. 

The  prototype  HGDS  has  been  described  by  Helms  and  Raby.3  The  sample  subsystem  consists  of  five 
sample  lines,  each  continuously  pumped,  plus  zero  and  span  gas.  The  zero  gas  is  ultrapure  nitrogen, 
and  allows  measurement  and  subtraction  of  background  gases  within  the  mass  spectrometer.  The  span  gas 
consists  of  precisely  known  amounts  of  each  gas  to  be  measured,  to  allow  generation  of  calibration 
(sensitivity)  coefficients.  The  mass  spectrometer  is  a commercial  quadrupole  type,  with  automatic 
pumpdown,  shutdown,  and  bakeout,  and  a mass  range  of  0-300  AMU.  The  digital  logic  controller 
is  built  of  individual  integrated  circuit  chips,  some  250  in  all.  The  operator  selects  up  to  eight 
gases  to  be  measured,  and  up  to  five  sample  lines  to  be  automatically  scanned.  The  system  is  capable 
of  performing  an  automatic  self-calibration  on  operator  command.  Drift  and  measurement  error  over 
an  eight-hour  period  are  typically  less  than  five  percent  (5%)  of  the  reading.  Correlation  against 
simulated  leaks  is  better  than  0.99. 

The  operational  Hazardous  Gas  Detection  System  for  the  Shuttle  program  (shown  in  Figure  3)  was 
designed  and  built  by  UTI  Instruments,  Inc.,  Sunnyvale,  CA.  The  first  of  four  units  was  delivered 
to  NASA/KSC  in  December,  1979.  The  design  has  been  described  in  papers  by  Bunyard  et.  al.,*  and 
Wells.5  It  consists  of  the  same  mass  spectrometer  used  in  the  prototype,  and  a similar  sampling  sys- 
tem. These  are  depicted  in  Figure  4.  However,  the  digital  logic  controller  is  replaced  by  three 
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Zi log  Z-80A  Microprocessors.  One  controls  the  sampling  system,  one  the  mass  spectrometer,  and  one 
acts  as  overall  system  controller.  All  programs  are  contained  in  EPROM  read-only  memory.  Extensive 
health-check  instrumentation  is  included  to  warn  the  operator  of  failures  which  might  invalidate  the 
data.  This  includes  sample  selector  valve  and  sample  transfer  pump  failures,  analog  pressure  and 
flow  measurements  on  both  the  sample  subsystem  and  the  mass  spectrometer , and  various  fault  indica- 
tions on  the  vacuum  system,  mass  spectrometer,  and  microprocessors. 

The  operator  interface  is  extremely  user-friendly.  Guided  by  "prompt"  messages  on  the  local  con- 
trol panel,  the  operator  enters  the  mass-to-charge  ratio,  the  measurement  range,  and  the  calibration 
gas  concentration  for  each  gas  to  be  measured.  The  system  performs  an  automatic  calibration  by 
locating  the  mass  peaks,  and  generating  background  (zero)  and  sensitivity  coefficients  for  each  gas. 
The  operator  can  check  or  refresh  the  calibration  at  any  time. 


Figure  3.-  Space  Shuttle  HGDS. 


Figure  4.-  HGDS  schematic. 
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HGDS  PERFORMANCE 


Among  the  most  important  measures  of  performance  for  any  analytical  instrument  are  speed  of  re- 
sponse, detection  limit,  accuracy,  and  stability.  The  HGDS  has,  in  general,  met  or  exceeded  its  per- 
formance design  criteria.  Initial  acceptance  tests  and  periodic  performance  tests  are  run  to  assure 
optimum  performance  of  the  system. 


RESPONSE  TIME 

THE  HGDS  draws  samples  from  the  200  foot  Orbiter  sample  line  in  less  than  twelve  seconds,  and 
from  the  400  foot  External  Tank  Intertank  Area  sample  line  in  less  than  twenty  seconds.  The  design 
goal  was  30  seconds  or  less.  Response  at  the  instrument  is  virtually  instantaneous.  The  system  re- 
sponds to  50%  of  a change  in  concentration  in  one  second,  and  90%  of  a change  in  two  seconds.  The 
HGDS  samples  up  to  eight  different  gases,  one  each  second.  In  addition,  there  is  a one-time  20  sec- 
ond delay  prior  to  analysis  each  time  a new  sample  line  is  selected,  to  assure  adequate  purge  of  the 
previous  sample.  With  the  20  second  delay  plus  8 seconds  of  measurement  time  for  each  of  four  lines, 
the  HGDS  can  sample  all  four  areas  of  the  Shuttle  in  1 minute,  52  seconds,  well  within  the  design  goal 
of  2 minutes.  Considering  a maximum  sample  transport  time  of  20  seconds,  plus  up  to  eight  seconds 
to  analyze  all  gases,  changes  in  concentration  for  any  one  area  on  the  Shuttle  can  be  sampled,  ana- 
lyzed, and  reported  in  30  seconds  or  less. 


DETECTION  LIMITS  AND  ACCURACY 

Detection  limits  are  primarily  a function  of  the  precision  (repeatability)  of  a measurement  sys- 
tem. A detailed  study  of  both  the  accuracy  and  precision  of  the  HGDS  was  undertaken.  Data  for  hydro- 
gen and  oxygen  are  shown  in  Table  1 and  2,  and  in  graphical  form  in  Figures  5 and  6.  Similar  studies, 
albeit  less  detailed,  were  conducted  for  helium  and  argon  with  similar  results.  From  these  data,  it 
can  be  conservatively  stated  that  the  HGDS  accuracy  is  +/-5%  of  the  reading  or  +/-20  ppm,  whichever 
error  is  greater.  Furthermore,  using  twice  the  standard  deviation  as  a criterion,  the  detection 
limit  for  hydrogen  is  40  ppm,  and  for  oxygen,  helium,  and  argon,  less  than  10  ppm. 


TABLE  1.  HGDS  ACCURACY  AND  PRECISION  FOR  HYDROGEN 


Theoretical 

Concentration 

HGDS  Reading 
(Average) 

Error 

(Average) 

Standard 

Deviation 

Number 
of  Samples 

4040  ppm  H2 

3971  ppm 

-69  ppm 

29  ppm 

6 

1060  ppm  H2 

1037  ppm 

-23  ppm 

25  ppm 

8 

491  ppm  H2 

511  ppm 

+20  ppm 

22  ppm 

25 

250  ppm  H2 

258  ppm 

+8  ppm 

13  ppm 

25 

100  ppm  H2 

96  ppm 

-4  ppm 

23  ppm 

25 

50  ppm  H2 

55  ppm 

+5  ppm 

22  ppm 

25 

24  ppm  H2 

27  ppm 

+3  ppm 

11  ppm 

25 
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TABLE  2.  HGDS  ACCURACY  AND  PRECISION  FOR  OXYGEN 


Theoretical 

Concentration 


HGDS  Reading 
(Average) 


(Average) 


Number 
of  Samples 


3640 

ppm 

o2 

3696 

ppm 

+56 

ppm 

13 

ppm 

6 

1060 

ppm 

02 

1056 

ppm 

-4 

PPm 

23 

ppm 

8 

505 

ppm 

02 

502 

ppm 

-3 

ppm 

8 

ppm 

16 

255 

ppm 

02 

249 

ppm 

-6 

ppm 

9 

ppm 

19 

96 

ppm 

02 

113 

ppm 

+17 

ppm 

3 

ppm 

19 

49 

ppm 

02 

49 

ppm 

0 

ppm 

2 

ppm 

16 

26 

ppm 

02 

31 

ppm 

+5 

ppm 

3 

ppm 

20 

DRIFT 

The  HGDS  was  operated  without  operator  intervention  for  12  hours.  Data  was  read  hourly. 
The  system  alternately  sampled  a test  gas  cylinder  and  a zero  gas  (pure  GN2)  cylinder.  .Worst 
case  peak  to  peak  drift  for  any  one-hour  period,  and  for  the  entire  test,  are  reported  in  Table 
3,  and  shown  in  Figure  7. 
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Figure  7.-  Time  (hours). 

TABLE  3. 

Test  Gas 

1-Hour 

12-Hour 

Gas 

Concentration 

Drift 

Drift 

h2 

1060  ppm 

44  ppm 

66  ppm 

He 

105  ppm 

2 ppm 

10  ppm 

°2 

1060  ppm 

17  ppm 

95  ppm 

Ar 

196  ppm 

7 ppm 

10  ppm 
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DESIGN  IMPROVEMENTS 


Like  many  computer-based  systems,  the  HGDS  has  suffered  from  AC  power  line  noise.  Due  to  exces- 
sive noise  on  the  Mobile  Launcher  Uninterruptible  Power  System  (UPS),  the  HGDS  was  placed  on  a dedi- 
cated mini -UPS,  which  solved  the  power  related  problems. 

The  HGDS  uses  an  ion  pump  to  achieve  the  requisite  vacuum  of  one-billionth  of  an  atmosphere. 

This  type  of  pump  is  susceptible  to  eventual  hydrogen  saturation  and  subsequent  spontaneous,  periodic 
elution,  called  "burping".  This  causes  a degradation  of  measurement  precision.  The  only  solution  is 
replacement  of  the  ion  pump.  A recent  modification  has  made  this  a simple,  risk-free,  one-hour  proce- 
dure. 


Several  minor  microprocessor  firmware  "bugs"  have  been  identified  and  corrections  are  in 
work.  Component  faiures  have  been  within  acceptable  limits. 


APPLICATIONS 

The  HGDS  is  used  to  make  critical  go  - no  go  decisions  during  the  Space  Shuttle  countdown.  The 
Launch  Commit  Criteria  Document  specifies  the  maximum  allowable  limits.  A concentration  of  800 
parts  per  million  of  hydrogen  or  oxygen  is  considered  unacceptable  for  flight.  Leakage  of  this  magni- 
tude at  preflight  propellant  pressures  could  indicate  a leak  which  would  create  flammable  conditions 
when  the  propellants  are  at  the  much  higher  flight  pressures.  A concentration  of  10,000  parts 
per  million  of  hydrogen  or  oxygen  (25%  of  the  lower  flammable  limit)  is  considered  an  immediate  on- 
pad  hazard. 

The  most  notable  success  of  the  HGDS  was  the  detection  of  hydrogen  leaks  on  two  of  Challenger's 
main  engines  during  the  STS-Flight  Readiness  Firings,  as  shown  in  Figure  8.  In  the  ensuing  investiga- 
tion, incipient  leaks  were  found  in  the  third  Challenger  engine,  and  in  a spare  engine.  All  three 
engines  were  ultimately  removed  and  repaired,  thus  avoiding  a potential  catastrophe. 

As  a result  of  lessons  learned  during  the  STS-6  hydrogen  leak  investigation,  the  accuracy  and 
sensitivity  of  the  HGDS  is  now  used  to  perform  an  in-place  end-to-end  helium  leak  check  on  the  entire 
Orbiter  Main  Propulsion/Engines  system.  In  addition,  the  HGDS  will  be  used  to  leak  check  the 
ground-to-Orbiter  hydrogen  and  oxygen  umbilical  disconnects.  It  replaces  a laboratory  gas 
chromatograph  and  operator  which  were  previously  flown  in  from  California  before  each  launch  to  per- 
form the  leak  check. 
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CONCLUSIONS 


The  HGDS  is  an  accurate,  stable,  and  sensitive  analytical  instrument.  It  can  make  reliable  meas- 
urements of  a variety  of  gases  at  a few  parts  per  million.  Launch  vibration  has  caused  only  one  minor 
failure  in  six  launches.  Calibration  can  be  verified  and  refreshed  in  real  time,  thus  allowing  high 
confidence  to  be  placed  in  the  data.  It  has  demonstrated  its  importance  to  the  Space  Shuttle  program 
by  detecting  leaks  which,  if  uncorrected,  could  have  caused  a catastrophe.  With  the  advent  of  cryo- 
genic payloads  such  as  Centaur  within  the  Space  Shuttle  Payload  Bay,  that  importance  can  only  in- 
crease. 
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16.  Abstract 

This  publication  is  a compilation  of  the  papers  prepared  for  the  Space  Shuttle  Technical 
Conference  held  at  the  NASA  Lyndon  B.  Johnson  JSpace  Center,  Houston,  Texas,  June  28-30, 
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To  provide  technical  disciplinary  focus,  the  conference  was  organized  around  10  technical 
topic  areas:  (1)  Integrated  Avionics,  (2)  Guidance,  Navigation,  and  Control,  (3)  Aero- 

dynamics, (4)  Structures,  (5)  Life  Support,  Environmental  Control,  and  Crew  Station, 

(6)  Ground  Operations,  (7)  Propulsion  and  Power,  (8)  Communications  and  Tracking, 

(9)  Mechanisms  and  Mechanical  Systems,  and  (10)  Thermal  and  Contamination  Environments 
and  Protection  Systems. 

The  papers  in  each  technical  topic  which  were  presented  over  the  3-day  conference  period 
provide  a historical  overview  of  the  key  technical  problems  and  challenges  which  were 
met  and  overcome  during  the  development  phase  of  the  Space  Shuttle  Program.  Taken  as  a 
whole,  these  papers  provide  a valuable  archival  reference  to  the  magnitude  and  scope  of 
this  major  national  achievement. 
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